Re: [Zope-dev] Re: ZCatalog and Unique IDs
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
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...
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? cheers, Chris
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
participants (2)
-
Chris Withers -
Tres Seaver