Re: [Zope-dev] Observer / Notification Interface Proposal
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Observer / Notification Interface Proposal
Michel Pelletier [EMAIL PROTECTED] wrote: I'll do both, this is absolutely a desperately needed feature in the ZCatalog. Currently, Cataloged items must take responsibility for notifying a catalog of their changes instead of the ZCatalog observing them. Amos and I talked about this over Pizza a couple weeks ago but we were thinking from a pretty Catalogcentric view; or at least I was. I was considering an interface like the new Security API that could be imported in python and used to discover and notify catalogs of object changes. But this now seems to me to be some kind of pattern where objects need to discover an appropriate or canonical resource, like a catalog. This interface should be defined also, so that newly-born objects can notify a resources of their existence. I've added this to the InterfacesWiki http://www.zope.org/Members/michel/Projects/Interfaces/Discovery Thoughts on how they relate? Are they the same thing? I think this pattern is orthagonal to the ObserverAndNotification pattern, but is crucial to making things like TheClassFormerlyKnownAsCatalogAware and Ken's new WikiRelationship object work. CORBA solves this by mandating that the ORB provide a lookup method:: def resolve_initial_references( resource_type ): where resource_type is a well-known string like 'NamingService', etc. In our case, perhaps it needs to be:: def findNearestResource( meta_type ): which causes a walk up the containment hierarchy, searching for objects of the given meta_type. Tres. -- = Tres Seaver [EMAIL PROTECTED] Digital Creations "Zope Dealers" http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Observer / Notification Interface Proposal
Evan Simpson wrote: This exists! (sort of). ObjectManager.superValues accepts a list of meta_types, and returns a list of all objects of those meta_types which can be found in any ObjectManager in the current one's acquisition context. and has done for ages... the original Squishdot code uses this to find appropriate mailhosts and I'd be suprised if ZSQL methods didn't do the same to find databse connections... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Observer / Notification Interface Proposal
Michel Pelletier wrote: There allready exists such a thing, superValues([meta_type]). But I think this is too weak to use as a discovery protocol. An observable may not know or care what type of observer it wants to discover. Also, when it finds a number of various resources, catalogs lets say, does it just notify them all? Is there a concept of a default? Can they negotiate? Can this be limited by security? Take our Free Zope server, we don't want something to discover everyone else's ZCatalog's What about non-security related? There may be similar instances where you don't want to discover anything other than a specific catalog... Also, can an observer that gets notified during discovery just turn around and so 'no, I don't want to do anything with your notification'? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Observer / Notification Interface Proposal
At 07:19 PM 5/24/00 -0400, Tres Seaver wrote: I have started a page for an implementation of the GangOfFour Observer pattern within Zope: URL http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificat ion Please comment, either here or in the wiki. Is this only for events occurring within a transaction, or across transactions? If across transactions, how do you intend to handle persistent references, acquisition, and cross-database references? (My suggestion would be to use a path to the callable.) Second, I think there should be an opportunity for the observer to specify more detail about what it wants to be called *for*. I.e., either a specific event or an event mask, to avoid unnecessary calls for irrelevant events. I realize this is all very implementation oriented, but that's me. :) (Oh, btw on "ObserverInterface", I'm guessing you mean the contract requires that *observable* not worry about delays, not the other way around.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Observer / Notification Interface Proposal
"Phillip J. Eby" wrote: Is this only for events occurring within a transaction, or across transactions? If across transactions, how do you intend to handle persistent references, acquisition, and cross-database references? (My suggestion would be to use a path to the callable.) Note that the scaling requirement (no blocking/long-running actions inside the notification call) is intended to support intra-request notification. A ConcreteObserver implementation which needs to perform such work (e.g., send an e-mail message, etc.) will have to extract whatever data it needs from the subject and enqueue it for processing in some other thread, by the asyncore machinery, etc. Note as well that it would be possible to install an Observer which could "veto" the change by raising an exception (a clever ConcreteSubject might ignore such a veto, of course). I'm don't have any use case in mind for a cross-transaction "event". Second, I think there should be an opportunity for the observer to specify more detail about what it wants to be called *for*. I.e., either a specific event or an event mask, to avoid unnecessary calls for irrelevant events. I considered this, and decided that it would be simpler to put the EventFilter in a "shim" object (e.g. a high-pass filter) which would sit between the actual subject and observer. Consider stringing together a shell pipeline, e.g.:: ps -aux | grep tseaver | . | sort" Each piece has a very limited set of responsibilities, but stringing them together arbitrarily conveys enormous power. I also have hopes for a set of federated, filterable NotificationChannels (like CORBA's NotificationService) which would allow Observer-in-Zope to scale up enormously. I realize this is all very implementation oriented, but that's me. :) (Oh, btw on "ObserverInterface", I'm guessing you mean the contract requires that *observable* not worry about delays, not the other way around.) Changed it to 'subject' -- thanks for pointing it out! Thanks for the feedback! Tres. -- === Tres Seaver[EMAIL PROTECTED] Digital Creations"Zope Dealers"http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
