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

[Steve Alexander]

> The global event service cannot act the way you describe, IMO.  It 
> should not know anything about locations or traversal; moreover, since 
> it is a global service outside of the persitent tree, clients can't 
> subscribe persistently unless we write something to file or do something 
> similar, none of which I think we want to do.

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


class IGlobalEventService(IEventService):
     """The global event-service does not allow normal subscriptions.

     Subscriptions to the global event-service are not persistent.
     If you want to subscribe to the global event-service, you need
     to use the 'globalSubscribe' method instead of the 'subscribe'
     method.
     """

     def subscribe(subscriber, event_type=IEvent, filter=None):
         """Raises NotImplementedError."""

     def globalSubscribe(subscriber, event_type=IEvent, filter=None):
         """Add subscriber to the list of subscribers for the channel."""

So, we don't need to worry about the problem of distinguishing between 
the GlobalEventService and local EventServices.
The root folder should always have a local EventService. If it doesn't 
have one, local subscribers will get a NotImplementError when they try 
to subscribe to the global EventService.


> I also don't like the fact that we cannot subscribe via objecthub hubid 
> via this method.  As Ulrich and I discussed, though, an objecthub hubid 
> is not unique: a reference to the objecthub and a hubid from that 
> particular objecthub is the only unique combination.

While this is true of object hubs in general, this is not true of the 
ObjectHub service.

I suggest that an event service or an event channel should be able to 
take subscriptions by object hub id, and this id must be interpreted as 
relative to the object hub service.

It is the responsibility of the object hub service to deal with trading 
its registrations among higher-up object hub services if you add and 
remove object hub services.

For now though, we can meet this responsibility by saying that there is 
at most one object hub service per site, and if you add a site with an 
object hub service, that site must also have an event service.
This requirement is met by the initial Data.fs produced in Zope 3, as 
its Root Folder has both an Event Service and an Object Hub.


> Unless we make 
> some hard rules about ObjectHub usage (which might be a *very* good idea 
> for a number of other reasons, such as indexes) then an objecthub 
> subscription needs to be a tuple of hubid and path to pertinent object 
> hub, or somesuch.

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 imagine there will be application-specific indexes that will want to 
interpret their hubIds relative to some application-specific object hub 
(not the ObjectHub service).

In general, I think that most things that care about hubIds will only 
care about hubIds from one particular source of hubIds -- the ObjectHub 
service, or some other application-specific ObjectHub. I think that in 
general indexes do not need to store a tuple of (which_hub, hubId).


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

For now, I suggest neither advocating nor prohibiting multiple sites, 
each with its own object hub service. We should actively support one 
object hub and one event service at the root folder.


> Does that imply a new method of "hubSubscribe" that remembers the path 
> to the objecthub used and the hubid received?  Surely not: that leads 
> down a path of method proliferation similar to what we saw in Zope 2 
> code.  Can "subscribe" also take the tuple of a hubid and a wrapped 
> object hub or a path thereto?  That sounds ugly.

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.


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.

--
Steve Alexander