"Phillip J. Eby" wrote:
> Is this only for events occurring within a transaction, or across
> transactions?  If across transactions, how do you intend to handle
> persistent references, acquisition, and cross-database references?
> (My suggestion would be to use a path to the callable.)

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

I'm don't have any use case in mind for a cross-transaction "event".

> Second, I think there should be an opportunity for the observer to
> specify more detail about what it wants to be called *for*.  I.e.,
> either a specific event or an event mask, to avoid unnecessary
> calls for irrelevant events.

I considered this, and decided that it would be simpler to put the
EventFilter in a "shim" object (e.g. a high-pass filter) which would
sit between the actual subject and observer.  Consider stringing
together a shell pipeline, e.g.::

  ps -aux | grep tseaver | ..... | sort"

Each piece has a very limited set of responsibilities, but
stringing them together arbitrarily conveys enormous power.

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.

> I realize this is all very implementation oriented, but that's
> me.  :)
> (Oh, btw on "ObserverInterface", I'm guessing you mean the
> contract requires that *observable* not worry about delays, not the
> other way around.)

Changed it to 'subject' -- thanks for pointing it out!

Thanks for the feedback!

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 - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to