From a posting from Joe DiMartino dated 12/19/2002:

Hello OCF!

Here is a cut at the event notification API without membership, etc.
I have gutted most of the extra text about the scope and context that
this event service expects.

Note: I have not spent any time to figure out the docbook format that
was suggested. It's still ascii, but changed to be more man-page'ish.

Highlights:
h1. removed all non-event subject matter (membership, etc)

h2. name changes for clarity:

		replaced 'register' with 'subscribe',
		replaced 'class' with 'topic',
		replaced 'callback' with 'on_event'

h3. added get_event() interface

h4. changed semantics of handle_events() to differ from get_event().
get_event() is the manual way to process events and requires
the use of poll/select and a file descriptor. handle_events()
[notice the plural now] will pass control to the event service
to make calling the on_event functions seem more automatic and
less like a clunky get_event().

Outstanding issues:
i1. file descriptor vs. event descriptor (was token)
If you recall, v0.2 returned a "token" from register() that
was passed to subsequent calls and needed to be converted to
a file descriptor for poll/select. A poll/select is inevitable
in this programming model, so in v0.3 the token was removed
and a file descriptor was returned instead. This cut out the
middle man (and a function or two), but Ram seems to still
want a token of some sort.

In this go, you will notice an "event descriptor" that takes
the place of the v0.2 token. There is also a way to convert
the ed into a file descriptor. I would prefer to put it back
to a simple file descriptor.

i2. on_event function replacement
In v0.2, there was a "set_callback" routine to swap out the
current on_event (callback) function. That was removed in
v0.3 because many thought it was extra complexity that would
not be useful. Alan disagrees, however, and wants it back in.

It is still absent from this pre-draft.

i3. publish interfaces
This partial pre-draft still does not cover message allocation,
message stuffing, and message/event publishing interfaces.

i4. distributed vs. local
There was some discussion once about the scope of delivery for
events. If an instance of the event service runs on every node
in a cluster, should all events in each event topic be seen at
all locations? Or, should there be some provision for "local
only" topics, such as "this node's connectivity".

In addition, making the event service available as a cluster-
wide service (for applications external to the cluster) has
slightly different implications than an event service intended
for the cluster (internal) components.

i5. creation of event topics
This is not covered yet. It can be done administratively or
with programming interfaces or both. This issue is tightly
coupled with #i4, as there may be a need to specify "local" or
"global" at topic creation time. In either case, there is
an event name space issue if it needs to be kept coherent
across the cluster.

I'm sure there are more outstanding issues, but I can't think of them
just now...

As ever, happy reading.

Happy Holidays!

• Joe DiMartino