[Zope-dev] Observer / Notification Interface Proposal

[Phillip J. Eby]

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.