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'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.
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.