[Zope-dev] Observer / Notification Interface Proposal

[Phillip J. Eby]

At 12:45 AM 5/25/00 -0400, Tres Seaver wrote:
>
>Ah, ok -- I was planning simply to leverage the ZODB's facilities for
>maintaining persistent references in the DefaultObservable mix-in; more
>elaborate schemes would be possible (for instance to support
>rack-mounted observers?)

Actually, just using a plain reference might cause you some problems.  If
you don't strip off the acquisition wrapper, you'll pickle the entire
acquisition tree for the subscriber, including the REQUEST and RESPONSE
objects.  But if you *do* strip off the wrapper, you'll call the observer
without its acquisition context, causing security and possibly other
problems.  I would suggest using object paths, ala ZCatalog, since this
fixes these problems as well as cross-database and outside-the-ZODB
references.  Also, it takes care of being able to pass Python-level methods
as observers, since you can't pickle a direct reference to a method.

The references don't have to be de-referenced unless an event actually
occurs, although the high cost of de-referencing objects (even without
using a path) does suggest to me that observers should at least register
some kind of channel name or list of names, to prevent needless
reactivations.  Unless, of course, the idea is for "subjects" to not
subclass Observable directly, but rather to have various "event" subobjects
which are callable observables.  Calling an "event" object could fire it,
relaying the event to the subscribers, who would subscribe to the
individual event sub-object, rather than to the main "subject" object.

An interesting side-effect of this approach is that it allows one to create
a subclass of "event" that can be added to any ObjectManager subclass.  One
could also create another subclass of event as a methoid for use in
class/ZClass definitions.  This subclass would store its subscription data
in its parent object, allowing the event object itself to be shared across
instances of the class.

Still another interesting possibility is the idea that event objects could
define their own calling parameters, and optionally relay those to the
observers, which would allow a more interesting dataflow.

In the work I've been doing on my SWARM project, workflow Plan objects have
a collection of Event objects which were planned to work similarly to this,
but a bit more complex.  Event objects were going to have Properties, and
Plans also had "Roles" (relationships to a workflow instance) which
effectively were the subscribers of the events.  Role objects receive all
event firings, and selectively forward or transform them for their
"audience" (the objects in that relationship to the workflow instance).
Plans and Phases could also have Forms which were effectively input forms
for the properties of an Event.  Last, but not least, calling the Event
object with property data would create an "event instance" object which
would have methods for such things as "don't process this event further",
and which would contain all the data for that firing.

All that is probably overkill for this interface, but the basic idea of
callable "event" sub-objects which are subscribed to by observers is I
think a useful pattern to apply here.