Jim,

I am not entirely sure which part of my message you are answering to, so I
prefer to outline the situation in general.

I know many developers who want the existing events mechanism to be somehow
improved. A long while ago this question was raised in IB-Architect and I
have also seen it in other forums as well. There were a few solutions
proposed, some of them require just minor engine modifications, and some
require this part of the architecture to be completely redesigned and
reimplemented. Now the source code is open and everyone who is nearly
concerned in the future of Firebird has the chance to contribute his efforts
to the development process. Since I could dedicate the rest of my spare time
to the Firebird project, the events question came back to me. I knew it
wasn't planned for the first release, but I am one of those who are
interested in such improvement and I have decided to work on it.

The wildcarding of event names was a proposal that was raised more often
than not and it seemed to be easier to implement. The idea is to allow
client to use (*, ?) symbols to register the interest in more than one
event. Today, if I wait for event 'A?' and it is posted from any SP, I am
notified about this event only. If the wilcarding is implemented, I catch
also 'A1', 'A2', etc. events. How can it help to develop more powerful
applications (read: why is it needed at all)?

Just an example. As far as I remember, someone asked a question in one
forum: how can I monitor in my grid the changes made by other users who work
with the same table? A decision with a trigger that post a single event was
proposed. But he wasn't satisfied, because he didn't want to refresh the
whole grid. Then someone else (Helen, weren't it you?) advised to post from
the trigger an event that contains PK of the modified record and on the
client side listen for all events that match rows displayed on the screen.
As for me, it is terrible approach, but it looks to be the best solution
that was available until now. But with the introduction of wildcarding it
becomes quite simple to react with the given resolution (row/table/database
level) to any things that happen within database, because of (for example):
post_event 'EMPLOYEE' || '_INSERT_' || CAST(new.ID AS VARCHAR(10)), which
can be easily parsed on the client side.

How it should be used? The algorithm is exactly the same:

1. Allocate EPBs with isc_event_block()
2. Call isc_que_events() or isc_wait_for_event() to start listening
3. Use isc_event_counts() to determine which events were posted

If you are working with old-style event mechanism, you won't see anything
new. Design is 100% compatible with the existing code.

The server is responsible for comparing the names of the posted events with
the names (I call them masks) of registered events. If they match, it must
deliver satisfying requests to the client side. The delivered packet should
contain all information about the actual event names and counts.

But with wildcarding, the current code of isc_event_counts will return that
event 'A*' has been posted, for example, thrice. But you will still guess,
what were the names of those three events which have matched your mask. So
there is a need for getting this information. Because the interface and
implementation of isc_event_counts cannot be changed without breaking all
existing applications, I was thinking about new API routine that could help
to solve this problem.

And, I wouldn't call this a 'significant change to the architecture'. The
basic architecture is still the same, just some implementation details are
changed.

Cheers,
Dmitry

P.S. I apologize if I haven't answered your questions as you hoped them to
be answered. In this case please direct me more precisely to the issues you
are interested in.