[Zope3-dev] Re: discussion about ObjectHub, EventService etc. (was event-meta.zcml...)

[Gary Poster]

Steve Alexander wrote:

> Right. And, the global event service already has a globalSubscribe() 
> method, and disallows use of its subscribe() method.
> This was implemented at the Sprintathon.

Ah!  OK.

...snip everything else fine...

> I think it is reasonable to write indexes and other such components that 
> expect hubIds to be relative to the object hub service.
>  From the point of view of any such index, there is only one object hub 
> service.
...
 > I think that in
> general indexes do not need to store a tuple of (which_hub, hubId).

As noted elsewhere, me too.  Cool.

>> (I'd very much like to say that object hubs cannot be nested without 
>> implying a completely new site, by the way: nested object hubs are a 
>> very scary thought to me.)
> 
> In these discussions, I'd really like us to be clear whether we're 
> talking about an object hub (of whatever kind), or about The ObjectHub 
> Service. 

Always the ObjectHub service in this case, as you probably guessed.  I 
think your point is a bit subtler, though...

> The naming is unfortunate -- perhaps we should rename the 
> service to be the ContentId Service or ContentHub service, and leave the 
> name "ObjectHub" to be the more general implementation of this service, 
> which can be used in ways other than as a service.

I am fine with the way things are now, naming wise, but also fine with a 
change should that be desired.

More to the point, you are addressing the idea from Casey to whcih I 
latched on to, I think: I see your point there, but the "filtered 
ObjectHub" service that is actually The  (local) ObjectHub may be 
important for other use cases.  Or maybe I'm wrong.  And we can explore 
this after the alpha, agreed.

> We could have an IZopeEventService, which extends an IEventService for 
> easy use in the Zope framework.
> 
> So:
> 
>   IEventService            Generic, useable outside of Zope.
>       ^                    Not specific about how subscribe() works.
>       |
>       |
>   IZopeEventService        Extends the semantics of the subscribe()
>       ^                    method to allow subscribtion by location,
>       |                    hubId relative to ObjectHub service, or
>       |                    physically locatable object.
>       |
>       |
>   IGlobalEventService      Has special globalSubscribe() method.
>                            Disables subscribe() method.
>                            Used as the global event service.

Ah well, one often prefers one's own ideas: the directSubscribe and the 
local subclassing global makes more sense to me.  But I'm amenable to 
this.  You mention about IEventService above that it is "usable outside 
of Zope".  The interface is, yes, but none of our implementations will 
be, so I'm not sure what kind of win that will be.  Whatever.

> The Event service would be registered as providing the IZopeEventService 
> interface.
> 
> I have excluded subscription by direct reference from my description of 
> IZopeEventService.subscribe. I think this is a yagni for local 
> subscribers in Zope, but I'm willing to be proved wrong with a 
> counterexample.
> If subscription by direct reference is needed, I think that should use a 
> different method that makes clear the security implications of doing so.

It would allow another kind of indirect subscriber for the future. 
YAGNI for now is fine and appropriate.  Moreover, I should remove all 
indirect subscriber stuff while I'm doing this refactoring.

Do I need Papal approval for this redesign and refactoring or are you a 
cardinal now, Steve? :-)

Gary