-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

mario ruggier wrote:
> At first I felt this is a nice idea... but then i thought of a number of
> issues, that made this lose its appeal for me:

Mario, reading your comments I think you are missing the point. In Durus
you access persistent objects via links from other persistent objects
(except for the root object, of course). The internal OID of each object
is not relevant for the application. The OID is only used internally.

So if the OID space is big, sparse and unpredictable, you can still
travel around your storage following links. But you can't just "try" a
random OID (using an internal, "undocumented", feature) and get
something in return. Currently, in a current durus storage, you can try
any OID less than your current OID (you can get it simply creating a new
object, to look in its inner and private details) and you probably hit a
valid OID, getting a valid unknown object. You just scaped your object
graph.

> - What about doing a "for key in get_root():" ?
> The world is your oyster, then... that is, if you like oysters.

The only issue is that clients must know the root of its object graph.
Current durus implementation does "OID(root) = 0". but that is not an
obligation.

The server simply must provide you a root object. You can navigate it to
fetch other objects, just like now. But since OID are no predictable,
you CAN'T fetch an object you are not linked to.

> - Objects in the db often have predictable keys, as per the class
> definitions, the layer being used between the application and durus,
> etc. This kind of undermines the unpredictability of the OIDs.

Do not mix class definitions with OIDs. There is no relation at all.
OIDs could be just 256 random bits from "/dev/urandom" :)

> - Nice simple applications such as QP's DurusDirectory, that you can
> just instantiate on a durus db, and you can browse the entire db, become
> considerably less friendly... this one uses the OIDs as URL path
> components, which therefore become more cryptic under such a scheme.
> Also, should you have "clone db" type utilities, the OIDs will
> drastically change on each cloning, making for very jumpy URLs. Plus, I
> like little facts such as root is always object 0.

Any durus application fetchs objects following links. It neves does a
direct OID "get", except for "root" object. Do not mix classes or object
hierachy with OID pattern generation.

> But keep the food coming ;)

:-)

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRGpgQ5lgi5GaxT1NAQLJ1AP/XdedeNF4LHQJatUA9IfyIux8X6qk9PvB
W3cYWxaFslg0PuJyvYyvl5vlOXiu9pP/+b99vVjUJP1WGmKoctbC7I9D86fU4dSM
Lrt23iM4zWO4rS+Ta4g8ykia1R8GeaDFwQFpGzkkTYgj0yfuBy8q8R4huys6a952
J/WTNHCw3fA=
=k9cW
-----END PGP SIGNATURE-----