Hi, I hope this is a stupid question but why does ZCatalog use the URL of an object to uniquely identify it? Why not just use a reference to the object? Persistent object identifiers must exist for the ZODB so why not use them instead? cheers, Chris PS: This would solve all the problems with ZCatalogs and virtually hosted sites... 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 ;-)
Chris Withers wrote:
I hope this is a stupid question but why does ZCatalog use the URL of an object to uniquely identify it?
Why not just use a reference to the object? Persistent object identifiers must exist for the ZODB so why not use them instead?
What happens when you have multiple ZODBs? Additionaly, this breaks encapsulation between the ZODB and applications built on it, which isn't such a good idea. -- Itamar S.T. itamar@maxnm.com
Itamar Shtull-Trauring wrote:
What happens when you have multiple ZODBs? Additionaly, this breaks encapsulation between the ZODB and applications built on it, which isn't such a good idea.
Good, it was a stupid question. :-) I guess when you catalog objects, you should make sure you use the REAL path identifier though, not one that's been mangled by virtual hosting. Hence the traversal interface? cheers, Chris
Chris Withers wrote:
Itamar Shtull-Trauring wrote:
What happens when you have multiple ZODBs? Additionaly, this breaks encapsulation between the ZODB and applications built on it, which isn't such a good idea.
Good, it was a stupid question. :-)
Not so stupid - I had the same discussion at IPC8 with me on the asking side.
I guess when you catalog objects, you should make sure you use the REAL path identifier though, not one that's been mangled by virtual hosting.
Hence the traversal interface?
Right. -- Itamar S.T. itamar@maxnm.com
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
Michel Pelletier wrote:
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.
I think that depends on how you define a URL. For me: /Site/object1 /object1 /Site/Site/Site/Site/object1 are all URLs, in a ZCatalog sense, that point to the same object and aren't very unique ;-) I agree the path from root to an object, with no aquisition, is unique, but only per instance of zope...
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.
I was thinking along the lines of a CORBA POID which, AFAIK, uniquely identifies an object on a global scale. Could Zope do something similar?
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.
agreed... ;-) Well, here's hoping it makes it into 2.2, I'd be interested to here people's views on the CORBA POID idea though... Chris
----- Original Message ----- From: Chris Withers <chrisw@nipltd.com>
I agree the path from root to an object, with no aquisition, is unique, but only per instance of zope...
I was thinking along the lines of a CORBA POID which, AFAIK, uniquely identifies an object on a global scale. Could Zope do something similar?
Well, here's hoping it makes it into 2.2, I'd be interested to here people's views on the CORBA POID idea though...
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") or as addresses or slots in which objects can be found ("the CTO"). In this case, an advantage to using the address stance is that it obeys the Zope pattern of keeping objects in context. A path always identifies a single object, along with a set of parents. An OID-derived object could have several paths (or no path at all!), and it would be difficult to extract any of them, given the bare object. In the case of Catalogs, much of the time we're probably not interested in cataloging "whatever lives at this path address"; 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. Cheers, Evan @ digicool & 4-am
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?
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? Chris
----- Original Message ----- From: Chris Withers <chrisw@nipltd.com>
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
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
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
participants (4)
-
Chris Withers -
Evan Simpson -
Itamar Shtull-Trauring -
Michel Pelletier