[Zope-dev] Observer / Notification Interface Proposal

[Tres Seaver]

"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