[Zope-dev] Re: ZCatalog and Unique IDs

[Tres Seaver]

Chris Withers wrote:
> 
> Tres Seaver wrote:
> > > who's the CTO?
> >
> > Jim is.
> 
> Okay, I get the joke now :-)
> 
> >  * "persistent" references are effectively required to be immortal:
> >     it is _mandated_ that one be able to stringify the IOR, copy it
> >    to a piece of paper, put the paper in a bottle, and cast it on
> >    the waves;  whoever opens the bottle should be able to transcribe
> >    the IOR, reify the reference from the string, and communicate with
> >    the object (which may be an entirely new "incarnation" created
> >    just for this request).
> 
> This is the sort of persistent reference I meant, it's one of the
> reasons I like CORBA as a model ;-)
> 
> > A general-purpose, persistable reference in Zope pretty much has to
> > be represented as an absolute containment path
> 
> I don't agree. What happens when you move an object? The object doesn't
> change so why should its persistent reference? In a similar way, what
> happens when an object moves between storages? I reckon it should have
> the same POID...

What you are missing in my description above is that CORBA persistent
IORs
may not map one-for-one to "real" objects -- there may be many IOR's
whose
requests are served by a single "real" object.  Persistent IORs encode a
promise that, if I come back and invoke on the IOR I got from the
bottle,
the ORB which published it must do one of the following:

 * locate / activate the corresponding servant object and delegate to
it;

 * return to my ORB a LOCATION_FORWARD message pointing to the place
   whither it moved;

 * raise a NOT_EXIST exception if the object has died and can't be
   resurrected.

CORBA IOR's can actually consist of multiple "profiles" each of which
encodes
a "search path" to find the object:

 * "endpoint" data -- address information with which to establish a
   connection to the POA (persistent object adapter) e.g., hostname/IP
   + port # for TCP, or pathname for AF_LOCAL sockets;

 * "POA ID" -- a (possibly hierarchical) name for the object adapter
   which published the IOR;

 * "object key" -- the ID for the object, unique *within the POA*.

Zope objects already have an OID which is unique within their storage;
the problem is that there is no useful way to massage an object given
only
its OID;  lots of Zope's machinery depends on knowing the traversal path
used to find it.

> 
> > A man with one watch knows what time it is;  A man with two is never sure.
> 
> That's not quite what I meant... An object is unique. It's aquisition
> context may give it more attributes to play with, but at the end of the
> day it is a seperate entity. This entity should have a unique, global
> identifier; it's POID.
>
> I think putting a path in front of this identifies the context, but
> doesn't really do a lot to identify the object.
> 
> I guess my view depends on _data_ being stored in the object rather than
> acquired. Is this the case?

The traversal path encodes more than just acquired attributes.  For
instance,
it is entirely possible for a single object to be stored in multiple
folders:  in one folder, tseaver might not even be able to *see* the
object,
while in another, I might be able to query or modify it, based on the
local roles assigned in each folder.  (Note that this can't be done
through
the stock management interface, but could be done easily in
"file-system"
Python).

Tres.
-- 
===========================================================
Tres Seaver                            tseaver@digicool.com
Digital Creations    "Zope Dealers"    http://www.zope.org