ObjectHub (was Re: [Zope3-dev] Big import blocks)

[Gary Poster]

Jeffrey P Shell wrote:
I'd rather someone tell me what the ObjectHub is, and
> when, where, and how to use it, than make it easier for me to import.

That's the second time I saw the request in passing on other topics, so 
here goes.

ObjectHub general goal:

   Provide a unique id (UID) for objects.

HubId closest Zope 2 analog:

   A ZCatalog RUID.  Primary differences are that it is consistent 
(i.e., does not have any semantics of changing on reindexing) and it is 
exposed (i.e., it is globally available rather than a private 
implementation detail).

Details and subtleties:

   Like the ZCatalog RUID, the ObjectHub keeps track of objects by path. 
  Thus, if the same object is mounted in two locations, if both 
locations were registered by the ObjectHub then the ObjectHub would 
consider them to be two objects.  Thus a more technically accurate name 
for the service might by "PathHub" or some such but I think "ObjectHub" 
conveys the intent and effect better.

   Also like the ZCatalog RUID, the ObjectHub's hubIds are kept valid 
through moves, and are removed for deletions.  The Zope 3 event system 
receives the various object change events and delivers them to the 
ObjectHub.

   If the object is registered with the ObjectHub, the hub makes any 
necessary changes to its own data on the basis of the change and also 
publishes a parallel hub event to the event service.  The hub event is 
similar to the original object event but uses the hubId as object 
identifier instead of the path.

   ObjectHub subscribers (clients) can then make any necessary changes 
to their data structure on the basis of the change.  They can also 
choose to raise an exception if the change violates an assertion in 
their data structures (such as breaking a required relationship) and 
thus turn back the whole transaction.

   ObjectHub clients are typically index-like objects, keeping track of 
object content, metadata, or relationships.  The ObjectHub itself is 
fairly simple, but it relies on the more complicated event service, and 
it is part of the larger set of cataloging machinery.  Cataloging is not 
yet done, and is waiting (last I heard) on SteveA's query service and 
possibly then on my object query plugin to Steve's service.  I know I've 
become utterly swamped and have had to pull away from Zope 3 
temporarily, but I think Steve was close to finishing his query service 
a while back.  He's polishing the hub itself and some of the services 
and other infrastructure on which it depends now, I think.

Future explorations:

   hubIds are intended to behave as unique ids.  Because hubids are only 
unique to one ObjectHub, having another ObjectHub in your site is a 
significant and possibly dangerous configuration decision.  These 
patterns have only begun to be explored and are recorded in the Zope 3 
wiki under the proposals section as "Advanced Object Hub Usage" or 
something similar.

Conclusion:

   If you simply want to refer to an object and have something else be 
responsible for keeping track of the object through any moves, the 
ObjectHub should be your tool for many such use cases.

   Some use cases will want more of a ZODB OID available in application 
space, in which the id is the same if it is the same object mounted in 
different locations.  These use cases have not yet been thoroughly 
explored in Zope 3 to my knowledge.

Hope that helps.

Gary