Subject: Event subscription -- properties (model and protocol)

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jun 2005 11:26:59 -0400

In the last event description I sent to the list, I proposed that event 
information would have two IDs, one for identifying the event, and one for 
indicating subscription to the event.

The properties information seems to create an opportunity to simplify 
this.  And to address some of the issue of aggregate registration.

Instead of declaring another ID, the subscription state of an event will be 
part of its properties.  Thus, the properties returned for a GET-PROPERTIES 
operation on an event path will include the event accessibility 
(unsupported, supported) and the subscription state.  Given that we may 
want to extend the subscription semantics, we will use an integer variable, 
with 0 meaning not subscribed, and 1 meaning subscribed.
This then gives an easy way to subscribe or unsubscribe to all events from 
the LFB, and to all instances of a given event on a table.
Remember that the event path will be event-base.event-id.subscripts 
(possibly with more than one subscript).  The subscripts indicate which 
table entry the event refers to.  Thus a subscriber or unsubscribe is a 
SET-PROPERTIES with a path.  If the path is just the event-base, one has 
changed the subscription to all events for the LFB.  If the subscribe or 
unsubscribe is the event-base and the event-id, but the event is defined in 
terms of a table, one has subscriber or unsubscribed to the entire table.
This does not allow for subscriber or unsubscribing in one reference to 
either all events on a given table cell, or to all events on a given 
table.  Given that presumably there are a modest number of events, it seems 
a good trade to aggregate the table, while requiring explicit reference to 
each event.

Yours,
Joel M. Halpern