[Zope3-dev] publishEvent bubble pattern

[Steve Alexander]

Gary Poster wrote:
> 
> 1. (publishEvent bubble pattern)

> So, this would mean an additional "caller=None" at the end of the 
> IEventService publishEvent method signature.

Taken in the abstract, we want to avoid event message loops.
We already have a different interface for subscribers and for the 
EventService: subscribers get notify()-ed, and event services get told 
to publishEvent().
So, I don't think we need to worry about loops between the event service 
and subscribers. However, we should think about avoiding loops among 
collaborating event services.

One way to do this is, as you suggest, to make publishEvent() take an 
optional "caller" argument, for when an event service calls 
publishEvent() on another event service.


What if there's an eventservice subscribed to a higher-up eventservice 
via an eventchannel?
In that case, I don't think the higher-up eventservice will be able to 
tell that the lower-level eventservice that originated the event is 
subscribed.


Another way of doing things is to take advantage of the ZODB concurrency 
guarentees, and have an EventService hold on to the event while it is 
sending it out. When it receives an event, it compares it to the event 
it is currently sending out (if any), and ignore the received event if 
it matches.

So, I don't think we need the "caller" argument.


There's also the issue of whether the "parent" event service gets 
notified (via publishEvent) before or after the direct subscribers. I 
suggest that the direct subscribers get notified before the parent event 
service, but that this behaviour is officially undefined.


> Presumably also at some point we may want an event service to be able to 
> decide to turn off publishing events to its parents, either filtered or just 
> entirely off.  I figure we can deal with that later.

Sure.

--
Steve Alexander