"Phillip J. Eby" wrote:
At 09:15 PM 5/24/00 -0400, Tres Seaver wrote:
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).
As you've probably noticed, I've been working on something similar for ZPatterns, but it's specifically oriented to the needs of Attribute/SheetProviders and Index/RuleAgents. The list of observers is effectively predefined, and the DataManager acts as a "tee" fanning out the events to the interested parties. However, subscription scope is per-transaction; the subscription takes place the first time an object hooks up with its DataManager in that transaction.
I added motivating examples to the two interfaces pages: e-mail notification and workflow state-machine transitions. Both of these involve persistent subscriptions.
I'm don't have any use case in mind for a cross-transaction "event".
Perhaps I was unclear. I was referring to maintaining the link between subject and observer for longer than a single transaction. That is, a persistent subscription.
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?)
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.
Hm. It seems to me that something like that would require persistent subscriptions to be of any real use, since re-subscribing on every transaction would likely be inefficient.
I apologize for the confusion -- I certainly didn't intend to convey that subscriptions were transient. As you note, that would be a less than useful "feature." -- ========================================================= Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org