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

[Steve Alexander]

> Yuck, furthermore, yuck. I would think it would be better to make the hubids 
> guids instead, and have an internal field in the guid that identified the hub 
> to the grand unified ObjectHub service.  But that's just me.

You mean a 'guid' that is unique within one Zope server, right? Not 
"Globally" unique.

In any case, I don't think we need this. From any location in Zope, 
there is just one ObjectHub service. A hubId is interpreted as being 
relative to that.


>>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.
> 
> I think that multiple exclusive hubs are likely necessary (for separate local 
> "sites" within the same Zope), but hierarchies of hubs, well, that sounds 
> like a minor nightmare...
> 
> OTOH It would be possible if the child hub eclipsed the parent hub such that 
> the client did not know it was there. The child hub would silently defer to 
> the parent if it needed to for whatever reason.
> 
> This would be a way to punt for now, since dealing with a hierarchy in this 
> way would be transparent to the client.

Good points. We need to think about this. I don't think we need to think 
about this before the alpha release.


> I think there should be only one hub visible to a normal client.

Yes.

> It should be 
> possible for an "advanced" client to deal with multiple hubs, but the onus 
> would need to be on that client to keep track.

I see how an advanced client would do this. I call yagni for now.


>>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.
> 
> Yup. Perhaps this is good enough, at least for now. And perhaps we could 
> create the illusion of multiple hubs, but in reality just keep everything in 
> one big honking BTree. Maybe the "child" hubs could actually be indexes on 
> the root hub.

There are two main use-cases here:

1: An application that needs to be synchronised among servers, or 
exported and imported, or copied and pasted. Such an application needs 
to have its own object hub, so it can control its own id space. It won't 
use the ObjectHub service.

2: You have two sites, but you want to be able to index across both 
sites, and copy and paste content and possibly indexes between sites.
In this case, there needs to be just one ObjectHub service serving both 
sites.


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

:-)

--
Steve Alexander