[Zope3-dev] event service and channel

[Jim Fulton]

Gary Poster wrote:
> 
> I'm building some event channel and service code, and have run into a few
> interesting decisions that I'd like to see if anyone has some feedback on.
> Here are the topics, so you can quickly decide what you're interested in;
> I'll get into them below.
> 
> 1. what publishEvent bubble pattern whould we use through multiple placeful
> event services?
> 2. what subscribe pattern should we use for multiple placeful event services?

I'll respond to both of these.  First, it is dogma that whether and how placeful
services collabroate with services above them or with global services is a 
policy/quality-of-service of the service implementation.

Second, Tres Seaver, who has a lot of experience with event systems feels strongly
that there should never be more than one event service in a system and that, 
therefore, it's a bad idea for any propigation to occur, at least among placeful
services.  I'm not sure I agree, but am willing to defer to his YAGNI for multiple
nested placeful event services absent specific examples of cases where there there 
is a  need for nested event services that isn't better handled by placeful 
event channels.

...

> 3. While some objects, like the ObjectHub, will be special event channels, we
> will want standard event channels for events of certain types: where should
> they live?

...

> Discussion

...

> 3. (Event channels)
> 
> This is less pressing, but...
> 
> While some objects, like the Object Hub, are specialized event channels,
> Tres' design also includes named event channels, which seem like a great
> idea.  If a certain event type will be subscribed to by many objects, make
> that event have its own channel, and subscribe to it.  Careful channel design
> could significantly reduce the churn of processing a given event publication.
> 
> How should these named event channels be accessible?  Where should they live?
>  What, in terms of Component Architecture, are they, even?
> 
> One idea is that they can live in event service as parts, and one can find
> and subscribe to them via a different method of the event service.
> 
> They could be services themselves, but that seems contrary to the idea of
> services, both theoretically (are they essential to the functioning of Zope?)
> and practically (the number of event channels could conceivably grow fairly
> high).

I suggest we call YAGNI on this for now till we need them.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org