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

[Gary Poster]

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)?

My full blather:

One of the concerns that has been discussed about the object hub is that 
nested, multiple object hubs will not play well with components that 
rely on them.

To some degree, this can be solved by, for a given hubid, also 
remembering the path to the object hub that gave it.  If this is 
accepted, though, that'll mean some (ugly?) changes to object hub 
clients such as the new text index.

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.

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.  A 
tougher recipe would be for separate sites that *occasionally* need to 
operate as a single one.

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.

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

Gary