[Zope3-dev] service names

[Shane Hathaway]

On Fri, 7 Feb 2003, Steve Alexander wrote:

> First there was the Events service.
> 
> (According to my proposed naming, this service doesn't actually manage a 
> collection of events, it allows you to send and receive events, so it 
> shouldn't be called 'events'. But I won't worry about that for now.)
> 
> The service did two things. It allowed you to publish events. And it 
> allowed you to subscribe to receive events.
> 
> But there were various architectural problems with having both of these 
> things, publishing events and subscribing to receive events, handled by 
> the same service. The solution was to have them handled by the same 
> service implementation, but by two different service types.
> 
> One service type allows you to subscribe to receive events.
> One service type allows you to publish events.
> 
> The Global and Local services for publishing events work in exactly the 
> same way. You just say 'publish(event)'
> 
> The global and local serivces for subscribing to receive events have to 
> work differently. The global one has to take care of per-process 
> subscriptions. The local one has to take care of persistent path-based 
> subscriptions.
> 
> We need two good names for these service types. I suggest 'Subscription' 
> and 'Publication'.
> 
> If these terms are too confusing, then 'EventSubscription' and 
> 'EventPublication'. But, that becomes a bit of a mouthful.

Do you think so?  They don't seem long to me.

Also, I think the word "publication" is already overloaded in the context 
of Zope.  Perhaps EventRouter?

Or... let's take a completely different look at the subject.  A pattern
that pervades both Zope 2 and Zope 3 is that objects implement at least
two interfaces: a run-time interface and a configuration interface.  The
publication feature of the event service is its run-time interface, and
the subscription feature is its configuration interface.

I think we should expect every component to implement both kinds of
interfaces.  I don't think that should mean that each service implements
two service types.

As I understand it, your reasoning for separating into two service types
is that global event services must implement a different subscription
interface than local event services.  I suggest that another way to solve 
the problem is the use of reference objects.  Rather than pass the 
listener of an event to the event subscription service, the application 
should pass a reference that, when called with a context argument, returns 
the listener.

If the even service is local, it can put the reference object in the
database (since references must be capable of storage in ZODB).  If the
event service is global, it may choose to discard the reference and
remember only the referenced object.

Shane