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

[Casey Duncan]

On Tuesday 17 December 2002 04:29 pm, Gary Poster wrote:
> Executive summary:
>=20
> We need to decide soon our take on multiple object hubs, because it wil=
l=20
> have implications on the implementation and possibly also the design of=
=20
> object hub clients.  Specifically, should we always consider object hub=
=20
> hubids as a tuple of (object_hub_path, hubid)?

Yuck, furthermore, yuck. I would think it would be better to make the hub=
ids=20
guids instead, and have an internal field in the guid that identified the=
 hub=20
to the grand unified ObjectHub service.  But that's just me.
=20
> My full blather:
>=20
> One of the concerns that has been discussed about the object hub is tha=
t=20
> nested, multiple object hubs will not play well with components that=20
> rely on them.

I think that multiple exclusive hubs are likely necessary (for separate l=
ocal=20
"sites" within the same Zope), but hierarchies of hubs, well, that sounds=
=20
like a minor nightmare...

OTOH It would be possible if the child hub eclipsed the parent hub such t=
hat=20
the client did not know it was there. The child hub would silently defer =
to=20
the parent if it needed to for whatever reason.

This would be a way to punt for now, since dealing with a hierarchy in th=
is=20
way would be transparent to the client.
=20
> To some degree, this can be solved by, for a given hubid, also=20
> remembering the path to the object hub that gave it.  If this is=20
> accepted, though, that'll mean some (ugly?) changes to object hub=20
> clients such as the new text index.

I think there should be only one hub visible to a normal client. It shoul=
d be=20
possible for an "advanced" client to deal with multiple hubs, but the onu=
s=20
would need to be on that client to keep track.

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

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

You can't please everyone ;^)
=20
> It is worth noting, I think, and by the way, that just because the=20
> object hub may need to be unified for *all* parts of a site, indexing=20
> clients of the object hub can still only index subsections of the site.

Yup. Perhaps this is good enough, at least for now. And perhaps we could=20
create the illusion of multiple hubs, but in reality just keep everything=
 in=20
one big honking BTree. Maybe the "child" hubs could actually be indexes o=
n=20
the root hub.
=20
> In any case, whether we choose to combine the object hub path with the=20
> hubid, or simply declare that One Object Hub Should Be Enough For=20
> Anybody (Who Isn't Ready For a Fight), the question of how to deal with=
=20
> multiple object hubs probably should be answered not too long after the=
=20
> alpha release (if not before).

If they want it, let them implement it 8^)

-Casey