[Zope3-dev] mild ramble: the object hub and site definition by services

[Steve Alexander]

Gary Poster wrote:
> Executive summary:
> 
> We need to decide soon our take on multiple object hubs, because it will 
> have implications on the implementation and possibly also the design of 
> object hub clients.  Specifically, should we always consider object hub 
> hubids as a tuple of (object_hub_path, hubid)?

No.
Certainly not when the hibId is relative to the ObjectHub service.

I suggest renaming the ObjectHub service to something else, such as the 
ContentHub service, to help distinguish uses of the ObjectHub in 
applications and as a central service. I'll use the new term below.

 From any particular place in zope, there is only one ContentHub 
(ObjectHub service). Most times, an index or other component that uses 
hubIds will understand that a hubId is relative to the ContentHub.

We have to consider carefully what happens when sites are created and 
removed, and Event Services and ContentHub services are added and removed.

For now, when you first start zope 3, an Event Service and an ContentHub 
service are created in the root folder's service manager. This should be 
sufficient for the alpha release, and will give us more time to explore 
the use-cases for having many sites within one zope server, and how we 
should treat ContentHub and Event services under different site 
configurations and reconfigurations.
For now, I say yagni. We can discuss it more in the breathing space 
after the alpha release.

For application-specific object hubs, indexes for such an application 
will know that the hubIds are relative to the application-specific 
object hub. This is an application domain problem, so we don't need to 
worry about it for the general-purpose indexes, event services and so forth.


> Another solution might simply be to acknowledge the problem. You'll need 
> some deep zen to hook up multiple object hubs well, no matter what, I 
> think.  This warning alone probably should be documented.

Right.


> Another step down this practical road might be to have recipes, as in 
> Stephan's documentation.  A way to set up *completely* separate sites 
> within the same tree might be useful.  My guess is that this would 
> include an event service and an object hub per site, at least.

Right.


> A tougher recipe would be for separate sites that *occasionally* need
> to operate as a single one.

Yes, that needs some thought, and some concrete motivating use-cases.
A related problem is changing from a situation of having many sites to a 
situation of having fewer sites at a higher level.


> It is worth noting, I think, and by the way, that just because the 
> object hub may need to be unified for *all* parts of a site, indexing 
> clients of the object hub can still only index subsections of the site.

Sure. There's the IHubEventChannel for this purpose.


> In any case, whether we choose to combine the object hub path with the 
> hubid, or simply declare that One Object Hub Should Be Enough For 
> Anybody (Who Isn't Ready For a Fight), the question of how to deal with 
> multiple object hubs probably should be answered not too long after the 
> alpha release (if not before).

Not before. Time is short and there is much to do.
I think we need to be informed by concrete use-cases and sensible 
constraints and invariants. Let's explore this at length and in depth 
next year :-)

--
Steve Alexander