When I invented event alters in1986 (?), the question was whether to associated user data with an event and the driving issue was resource consumption, primarily memory.  At that time, Interbase’s primary market was workstations which at that point tended to max out memory at 3MB and were often 1 or 2MB.  The Micro VAX-II, an increasingly popular server platform, had a 22 bit bus, limiting physical memory to less than 4MB.  The prospect of queuing up arbitrary quantities of memory for a slow responding client was daunting.  So I opted for a design without user data where unprocessed event did nothing but bump a counter.

That was then and this is now where even a $55 Raspberry Pi has 4GB of memory.

I recently designed and implemented database events in AmorphousDB.  Unconstrained by backwards compatibility (or, sigh, users), I had the luxury of approaching the problem with a clean sheet of paper.  The short version is that I went with events with associated user data.  Here is the slightly longer version.

An event can be declared in a user request (the Amorphous access language is block structured) or trigger.  The syntax is:

DECLARE EVENT <identifier> <value> [, <value> ]...

where <identifier> is an unquoted qualified name and <value> an arbitrary value expression.

Event handlers are managed by a couple of methods on the Amorphous Connection object:

virtual void registerEventListener(const char *eventDescription, EventListener *eventListener) = 0;

                                          

virtual void cancelEventListener(const char *eventDescription, EventListener *eventListener) = 0;

 

where:

              class EventListener

                             {

                             public:

                                 virtual void      eventPosted(Event *event) = 0;

                             };

 

              class Event

                             {

                             public:

                                 virtual const char*         getEventName() = 0;

                                virtual int                         getValueCount() = 0;

                                virtual ResultValue*       getValue(int index) = 0;

                             };

 

I considered and rejected using an event registration handle for cancelling an event registration as cumbersome and unnecessary.

 

I haven’t yet settled the semantics of the eventDescription string.  At the moment it’s a simple qualified event name.  When needed, I anticipate extending it to lists of event names and probably some sort of pattern matching string.  From an architectural point of view, it isn’t important.

 

Another problem I haven’t settled on a solution is security.  I really don’t want to give a malicious or ill-considered user the ability to send bogus events to another client.  When the dust settles, I’ll probably allow (but not require) event prefixes to be declared with a security policy that says who can declare them and who can receiving them. 

 

As for the problem of a slow message receiver, AmorphousDB is a pure server; if unprocessed event stack up in a client process, that his problem and not mine.

 

 

-- 
Jim Starkey