History for PortalEventsToolProposal

++added:

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.