[Zope3-dev] service names

[Gary Poster]

Shane Hathaway wrote:
> On Fri, 7 Feb 2003, Steve Alexander wrote:
>>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.

I'm ok with them.

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

Yes, very.  You're right.

> Perhaps EventRouter?

EventPublication and EventSubscription have more of a parallelism to 
them, and thus appeal to me more.

> 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.

Everything old is new again. :-)  This is exactly how I had implemented 
it before Steve and others started working with the event service 
extensively at the Rotterdam and Vilnius sprints.  They found it very 
onerous and, more importantly, breakable to be responsible for wrapping 
their subscribers with what then were implementations of 
IIndirectSubscriber.  Steve, other interested parties (Jim had the idea 
for the service division) and I agreed on the interface changes and 
adjusted the implementation for the alpha.

Other service components so far have not needed this pattern of siamese 
services, one for configuration and one for, well, action.  I myself 
find it a bit unintuitive, but (IMO) it is the strongest and most 
appealing balance we have found for the unique needs of the event 
service so far.

Which all isn't too say we can't go back, of course.  Just a bit of 
background. :-)  The indirect wrapper is a more elegant and flexible 
approach, IMO.  Just less practical "in the field", it seems.

At least for now, I'm inclined to go with EventPublication and 
EventSubscription and move on.

Gary