"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
> >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 [EMAIL PROTECTED]
Digital Creations "Zope Dealers" http://www.zope.org
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -