[Zope-PTK] New tool proposal: portal_events

Dieter Maurer dieter@handshake.de
Tue, 22 Aug 2000 23:22:08 +0200 (CEST)


Tres Seaver writes:
 > I am proposing to add a new tool, 'portal_events', to the
 > set of top-level tools provided by each portal.  This tool
 > would be a CORBA-style event channel, supporting the following
 > interfaces::
 > 
 >   class PortalEventSource:
 >       def register( observer ):
 >           """ Register an event sink for future notification.
 > 
 >               'observer' -- must be a traversable path to an
 >                 object conforming to the PortalEventSink interface.
 >           """
 > 
 >       def unregister( observer ):
 >           """ Unegister an event sink to prevent future notification.
 > 
 >               'observer' -- must be a traversable path to an
 >                 object conforming to the PortalEventSink interface.
 >           """
 > 
 >   class PortalEventSink:
 >       def notify( eventType, payload=None, **kw ):
 >           """ Process an event from an event source.
 > 
 >               'eventType' -- meant to be easily tested for filtering;
 >                 may be a well-known constant, a class object, etc.
 >               
 >               'payload' -- event data (or a lazy proxy therefore).
 > 
 >               'kw' -- meta-data about the event, especially useful
 >                 for filtering.
 >               
 >               Implementations of this interface contract to handle
 >               these notifications "quickly", without blocking.
 >           """
 > 
 > Here are the events I foresee flowing through 'portal_events':
 > 
 >  * ObjectManagers within the portal will notify the tool when
 >    objects are added or removed (the portal_catalog will subscribe
 >    to get these).
 >   
 >  * PortalContent will notify the tool when saving changes (the
 >    portal_catalog can subscribe to this one, too).
 > 
 >  * The portal_registration tool will notify of newly-added members.
 > 
 > Comments, please.
I like the idea.

However, I see three actors in the standard use case:

  the event source, such a "ObjectManager", "PortalContent", "PortalRegistration"

  the EventChannel (EventSource in your interface)

  the observer (EventSink in your interface)

The "EventChannel" would provide "register" and "unregister"
for "observers" and "notify" for event sources.



Dieter