Re: [Zope-dev] Re: ZCatalog and Unique IDs
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[EMAIL PROTECTED] Digital Creations"Zope Dealers"http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog and Unique IDs
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog and Unique IDs
Evan Simpson wrote: In the case of Catalogs, much of the time we're probably not interested in cataloging "whatever lives at this path address"; At the moment this is true, but Jim and I have discussed the possibility of ZCatalog being treating the paths less atomically and more as a sequence of nodes from root to the target, this way, you could ask the catalog for all objects below a certain point that match search criteria, etc. we want information about a specific object. Fortunately, the cut/copy/paste and rename implementations make the path approach workable. As a matter of fact, the new mountable database code required changing the clipboard operations to use paths instead of object monikers. And it looks like the event stuff is favoring paths also, I strongly suggest we make sure any of these needs is captured in the proposed traversal interface: http://www.zope.org/Members/michel/Projects/Interfaces/Traversal -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog and Unique IDs
Michel Pelletier wrote: At the moment this is true, but Jim and I have discussed the possibility of ZCatalog being treating the paths less atomically and more as a sequence of nodes from root to the target, this way, you could ask the catalog for all objects below a certain point that match search criteria, etc. Okay, now it starts to make sense... And I agree that the traversal stuff needs to handle this properly... My take on it is this: The URL is not the same as the path to the object. The path to the object should be unique, and always rooted at Zope's root, I don't think the Traversal Interface is strong enough on this point yet... Mapped to this path could be any number of ways of accessing/exposing objects which don't necessarily start at Zope's root. Take HTTP access through apache virtual hosting for example. Or exposing a sub-tree as files through FTP or WebDAV. Is this true or am I missing something? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog and Unique IDs
- Original Message - From: Chris Withers [EMAIL PROTECTED] who's the CTO? Jim Fulton, Chief Technology Officer. 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? A man with one watch knows what time it is; A man with two is never sure. That may not be a problem in this case, but I have a sneaking suspicion it would be. Still, if you can demonstrate that can be valuable and coherent, it could probably be done. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZCatalog and Unique IDs
Chris Withers wrote: Hi, I hope this is a stupid question but why does ZCatalog use the URL of an object to uniquely identify it? Because it's unique. Why not just use a reference to the object? How do you define that? If you mean reference in the strictly python sense, then I guess you're thinking about some kind of name or dictionary key in the catalog that is directly assigned the value of the observed object? This sorta gets back to the symbolic link vs. hard link analogies brought up in the past. Both have their dificulties, you cannot, for example, have a reference across databases, while you can map the physical path. Using a string like this could also allow you to quickly modify the catalog to index external resources. Persistent object identifiers must exist for the ZODB so why not use them instead? They change, I believe, over the revisions of the objects; and also this is a very low level identifier. I'm not certain. I think this attribute is _p_oid. cheers, Chris PS: This would solve all the problems with ZCatalogs and virtually hosted sites... So would a solid traversal interface that understood virtual hosting in Zope. I think the traversal interface is needed for other reasons but it should remove ZCatalog from the list of things that need it... not that I've just been bitten by this or anything ;-) I understand, but I think most of the biting was due to bugs than a flaw in the model. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
