On May 16, 2006, at 5:29 PM, Jesus Cea wrote:

> In fact, the other day I was thinking about using 128/256 bit OIDs and
> give "random" OIDs to clients when they request a new object. Why?.
> Because security: If your OID space is sparse and "random", you can
> allow access to hostile clients, since they only can read/write/delete
> objects if they know its OID, and OID would be no predictable. Just
> some
> food for the mind :p

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:

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

- 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.

- 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.

But keep the food coming ;)

mario