> Does the architecture or grammar of the Firebird Event model support
> adding parameters to events?
>
> I can picture a pair of BIGINTs being sent along the wire with the
> event, and a getEventData(eventId) call to go back to the server for
> more information.

Conceptually - no, practically you can generate a custom event name with
those IDs as part of the event name. Note, it is limited by 78 bytes.

> The former would OR all the parameters every time the event was posted
> before it was eventually broadcast to clients (like the way parameters
> for asynchronous windowing messages are handled). The latter would only
> work well if each event, when posted, had a unique ID associated with
> it, to differentiate the first broadcast of "eventA" from the Nth
> broadcast of "eventA". At the server, the programmer would be
> responsible for maintaining the data structure that would be sent back
> with the retrieval of the event data.

Some time ago I had short discussion with Jim Starkey on this topic. If I
understood him right, he is still fond of the current concept because it is
very lightweight and still opposed to the idea of events with parameters
which would consume server memory, etc.

Roman