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

[Janko Hauser]

Gary Poster wrote:
> 
> Casey Duncan wrote:
> 
>> On Tuesday 17 December 2002 04:29 pm, Gary Poster wrote:
> 
> ...
> 
>>> 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.
> 
> 
> One big honking BTree, one ObjectHub to bind them and one to rule them 
> all, is my preferred choice.  Nice 'n' simple.  The hubid can be treated 
> as a guid, which saves a *lot* of hassle and worries, and makes for 
> prettier clients.
> 
> And if I were forced at gunpoint to write a "site with occasionally 
> unified subsites" application, then the child index pseudo-hubs that you 
> describe--really, they are more like object hub filters, only giving a 
> subset of the hubid mapping in the top object hub--might be my first 
> choice of approach.  It seems reasonable and not too unpleasant to write.
> 
> So I guess that's two votes for making the following official, 
> documentable design decision:
> 
> You Can Treat HubIds Like Guids, At Least Until We Change Our Minds.
> 
> This would affect the current event service refactoring discussion too.
> 
> Any nay-sayers?

Not sure :-), I just want to describe a possible use case and you can
decide, if this can be done with one hub.

Document managing and archiving on an extranet site. This is one site,
where customers of a company and actors in the company have shared
information spaces, where all documents regarding the relevant business
process are handled. As this can become a rather high volume, we thought
of mounted storages, for each customer or group of customers. This would
allow the easy archiving, a way to save closed customer relations and
would allow a migration on several servers after time. For this each
storage should have it's own indices. It should be possible to remount
old storages and the hole functionality should work again. I'm not sure,
if this can be done with one central objectHub.

I think that mounting different storages with different types will be
used more in the future, also the exchange of storages  between
different servers.

just a note,

__Janko