[Zope-PTK] New tool proposal: portal_events

[Shane Hathaway]

Tres Seaver wrote:
>   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.
>           """

Don't we need to add a broadcast(eventType, payload=None, **kw) method
to PortalEventSource? Of course there are other ways to accomplish the
same objective; the best approach is open for debate.

Also, we might move register(), unregister(), and broadcast() into a
simple base class called "EventSource" then add a minimal subclass
called PortalEventSource.

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

Minor point: Should we require eventType to be immutable, thus allowing
it to be used as a key in a mapping?  It would also clarify the proper
usage.

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

* workflow status changes, which would be a separate event.

* additions to the discussion attached to an object.

Note that portal_events should eliminate the need for hook-like
functions.

Another point worthy of discussion is whether (and how) portal_events
should provide event filtering (which may or may not be useful for
scaleability.)

Shane