Roman Rokytskyy wrote:

>>I'm not at all sure that an event interface built around single events
>>is all that useful. If I were doing it, I'd want to ability to block on
>>one of any number of events and the ability to get a callback from a
>>dedicated listening thread.
>>
>>
>
>What would be a business case for waiting on multiple events?
>
>

Let me turn the question around. What is the business case for
building an interface that doesn't support the functionality of the
underlaying product?

The reason to handle multiple events is because most systems are
interesting in more than one named event. The classical example is
something that is watching stock prices or inventory levels or
something. The user picks what he wants to watch. The program blocks
on the set of events. When it wakes up, it figures out which fired,
does the necessary and appropriate processing, then loops. No need to
listeners or separate threads. A more sophisticated program might want
to be notified asynchronously when anything of interest changes so it
could popup dialog or message boxes. Another example is the original
Interbase librarian (marion). If somebody had a module or modules
checked out that you wanted, you could run a program that listened on
the module name for a checkin. Waiting on multiple modules was just as
easy as waiting for one.

Waiting on multiple events is a pain in the butt in virtually all
systems. Waiting one multiple event and reconstructing which fired and
the context for each is even worse. All that logic is rolled into the
event mechanism already, so application programmers don't have to
reconstructure it every time.

>As I understand, the idea is to define an event USER_CHANGED, an AFTER
>INSERT/UPDATE/DELETE trigger for USERS table that would fire such events.
>Application that would register a listener for the case when USERS table is
>changed. What would be the case to receive notifications for different
>events in the same listener?
>
>
>

Nope. That's not a very good way to do events, though some people use
it that way. The system is designed for fine granuality event
("something happend to Roman" or "Roman got fired"). The design
assumption is that vastly more events get posted than listened for. The
event manager, in turn, is designed to make it very cheap for a tree to
fall when nobody is listening.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376