At 09:24 PM 17/09/2004 +0000, you wrote:

>I wonder if it would be possible for the firebird developers to
>modify the event listener regisration code so that a client listening
>for events could register for events such as 'MY_EVENT*' and then be
>sent all events with names matching 'MY_EVENT*'?
>
>I think this capability would be benefical to both of us.
>
>For example: ...
>
>At present the server-side event notification is triggered by the
>invocation of POST_EVENT 'ANYNAME'
>There seems to be no possibility (please correct me anyone if I am
>wrong) to send an addittional parameter with 'ANYNAME', such as
>sending back a key for the record just inserted or updated. Inside
>the trigger or procedure calling POST_EVENT the event name can
>be "mangled" to produce "ANYNAME:1234567" but this changes the name
>of the event and on the client side only a client who has registered
>as a listener for an event named "ANYNAME:1234567" wil be notified.
>
>By contrast if a client could register as a listener for events
>like 'ANYNAME*' then they would get notice of
>event "ANYNAME:1234567", peel off the key value "1234567" and process
>the event 'ANYNAME' as they wish.
>
>So here is a simple case for expanding the event notification code to
>allow for registering for events named with wild card names.

Isn't this the opposite of what you asked for? You said you wanted your
client to be able to *ignore* any events that had been fired by its own
process.

>Is there a way to achieve this functionality with using the existing scheme?

You can already send an event that includes the user name (listen for/send
from server), e.g.
...
declare ThisEvent varchar(15) = '1234'||CURRENT_USER;
...
...
POST_EVENT(ThisEvent) ;

(provided your system has very short user names! Event names are limited
to 15 bytes )

Since the client application knows its username, you already have the
capability to have a client listen for its own events. But that's no good
for the generic purpose of events, which is to have everyone listen for an
event. If only the instigating client knows the name of the event, none of
the others knows what to listen for. If you add your original requirement -
to have the client ignore its own events - then this user-specific event
has nowhere to go.

Whether it would be a Good Thing to re-architect events to make them a
full-blown messaging subsystem isn't a subject for the support list but one
you might care to raise on firebird-architect, if you have strong feelings
about it.

Since (I think!) you are using IBO, why don't you just use DMLCaching? If
I've understood your requirements, it already implements exactly what you
want: clients listening for DML commits and optionally ignoring their own.

./heLen