[Zope3-dev] practice and theory: event service and connotations of "implementing an interface"

Gary Poster gary@zope.com
Thu, 19 Dec 2002 16:35:06 -0500


FWIW, as to the event service ideas, the end of this email was supposed 
to then ask for everyone's thoughts and votes--just to make clear that I 
am not making any kind of (doomed) attempt to "pronounce".  :-)  This is 
just my proposal on going forward.

Thanks

Gary

Gary Poster wrote:

> More practically, speaking about the event service, I am reneging on my 
> approval of the design described above and the "globalSubscribe" method.
> 
> Instead, I would like to make the following interface changes for the 
> goals we have identified (namely, let wrapped objects subscribe easily 
> in a wrapped manner, hopefully being able to take advantage of the hubid 
> service; and let it be impossible for them to subscribe to the global 
> service).
> 
> The description of Zope.Event.ISubscribable.subscribe will be as follows 
> (the only change is in the second paragraph):
> 
>     def subscribe(subscriber, event_type=IEvent, filter=None):
>         """Add subscriber to the list of subscribers for the channel.
> 
>         subscriber must implement ISubscriber, or will raise a
>         SubscriptionError.  Based on implementation or subclassed
>         interface, subscribable may also raise a SubscriptionError if
>         the subscriber does not meet other criteria.
> 
>         event_type, if supplied, is the event interface
>         about which subscriber should be notified, and must implement
>         IEvent.  The subscriber will be notified of all events of this
>         event_type and of subclasses of this event_type.
>         The default value, IEvent, as the parent type, is effectively a
>         single catch-all event type that will pass all event types to
>         the subscriber.
> 
>         filter, if supplied, must implement IEventFilter; subscriber
>         will be notified of events only if they pass.
> 
>         A subscriber may subscribe more than once, even if it has
>         already been subscribed with the same event type and
>         filter.  In this case the subscriber will receive multiple
>         calls to its notify method.
> 
>         If the subscriber implements ISubscriptionAware, this function
>         will call the subscriber's subscribedTo method.
>         """
> 
> The GlobalEventService will move to the newly-made home of 
> Zope.App.Event, proposed by Steve.  The 
> Zope.App.Event.GlobalEventService.IGlobalEventService will inherit from 
> Zope.Event.IEventService, which inherits from Zope.Event.ISubscribable. 
>  It will override the subscribe method as follows:
> 
>     def subscribe(subscriber, event_type=IEvent, filter=None):
>         """As Zope.Event.ISubscribable.  Will raise a SubscriptionError
>         if the subscriber is wrapped.
>         """
> 
> The LocalEventService will remain in 
> Zope.App.OFS.Services.LocalEventService (soon to be zope.app.ofs.event, 
> of course).  The 
> Zope.App.OFS.Services.LocalEventService.LocalEventService.ILocalEventService 
> will override the subscribe method as follows:
> 
>     def subscribe(subscriber, event_type=IEvent, filter=None):
>         """As Zope.Event.ISubscribable.  Will raise a SubscriptionError
>         if the subscriber is not wrapped.  Storage of wrapped object is
>         implementation specific, but must always call subscriber's
>         notify in wrapped context"""
> 
> The built in implementation will always try first to store the object 
> via the hubid service, and failing that will use an absolute path.
> 
> Gary
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
> 
>