[Zope-dev] Re: ZCatalog and Unique IDs

[Tres Seaver]

Chris Withers <chrisw@nipltd.com>
> 
> Evan Simpson wrote:
> > There are generally two ways (at least) to think about "object
> > identifiers".  You can think of them as unique labels for
> > specific objects, without regard for location ("Jim Fulton")
> 
> Me too...
> 
> > or as addresses or slots in which objects can be
> > found ("the CTO").
> 
> who's the CTO?

Jim is.

> 
> > In this case, an advantage to using the address stance
> 
> [snip path/catalog stuff]
> 
> > use paths instead of object monikers.
> 
> Why not do both?
> 
> Have an POID (CORBA style) to actually identify an object and then use
> paths of POIDS to identify stuff in a cotnext *when you need to*...
> 
> comments?

CORBA's Interoperable Object References come in two flavors:

 * "transient" references are valid only for the lifetime of the
   server (actually the POA) which creates them;  in this respect,
   they are like the actual Python object references of an activated
   object in Zope.

 * "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).

A general-purpose, persistable reference in Zope pretty much has to
be represented as an absolute containment path -- no other mechanism
I can think of will both survive a restart of Zope and deal with
objects which may live in another storage.

In CORBA terms, the "object id" part of the persistent reference
would be the containment path (the other bits of a CORBA IOR are the
hostname/IP address and port number of its server, or equivalent
endpoint data for other transports).

CORBA offers several interesting strategies for dealing with
persistent IORs, and binding them to the "servant" objects which
actually carry out the requests sent to the IOR:

 ServantActivator -- much like the ZODB, the SA keeps a list of
   currently active servants, and the IORs to which they are bound.
   When processing a request, the SA finds or activates 
   ("incarnates") the proper object/servant and delegates to it.
   This pattern is usually used  with the Evictor pattern, which
   deactivates ("etherializes" in CORBA terms) objects using a LRU
   (or other) policy when things get too crowded.

 ServantLocator -- keeps a pool of idle servants, binding them
   as needed to the IORs of incoming requests, and unbinding them
   according to a timeout or other policy.

 DefaultServant -- all requests are delegated to a single servant,
   who uses the object key to determine whom it impersonates.

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