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

[Guido van Rossum]

> 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,
[etc.]

Could you try that again without using Zope 2 analogies?  Being
ignorant of Zope 2 stuff (for better and for worse :-), definitions in
the form of comparisons to Zope 2 features don't help me.

AFAIK, the ObjectHub service doesn't ever look at the objects -- both
its internal data structures and its API are defined in terms of
paths, and whether or not there's an object at that path doesn't
actually concern the ObjectHub.

I wonder if the name isn't causing more confusion than clarity.
Certainly the "hub" part never made sense to me: this suggests that it
is a pretty fundamental central data structure, while in fact it is
only used for cataloging/searching.  (Which is important, but far from
fundamental IMO.)  And the "object" part of the name seems to be
factually wrong.

It's really about UIDs (Unique IDs) for paths.  I wonder if a name
like "uid service" wouldn't make more sense?

--Guido van Rossum (home page: http://www.python.org/~guido/)