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

[Steve Alexander]

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

Ok. I'll propose this as a renaming in a separate email that people can 
reply to and discuss.


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

Ok.

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

I'm guessing that we can write a useful non-zope-specific base 
EventService, and then derive ZopeEventService and GlobalEventService 
from that.

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

Ok. Great. I think it will be easy to add this stuff back in later if we 
find we need it.


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

I had a few conversations with Jim about this at the Vilnius sprint, 
although we didn't go into too many details. The main point was that in 
general, notification should happen by traversing to the object in 
context, not by direct "naked" reference.


I'd rather not distract Jim with this unnecessarily, as he has plenty of 
other things to watch out for right now. If you're fine about this, I'm 
fine about this, and Casey is fine about this, then I think that's just 
fine :-)

Any comments or thoughts, Casey?

--
Steve Alexander