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.