On May 17, 2006, at 1:29 AM, Jesus Cea wrote:

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

That would be a first ;-)

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

Yes, and no. I think in Durus, like in any other application context,
you do what the context allows you to do ;) In an interactive durus
client for example, you can do a get(oid)... you can also pass a known
oid around, as a ref to an object.

What maybe is confused in my thinking is that I am probably mixing up
the actual oid with the formatted oid... In the storage classes,
self.oid is an integer, which I take as permission to think of a oid in
its formatted form ;) Also, the interactive get(oid) functions on the
integer value.

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

But if you already can create (commit?) an object, would this not also
imply that you also have access to the root object? So a malicious
client could do any mischief it wants...


>> - 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" :)

Well, ok.  What I meant was that when you define a class, you often
want to declare an attribute's value to be unique amongst all
instances... and then use that value as predictable key for getting the
instance. But, in any case, if you can do the get using such a key,
you'd also have access to the root object...

mario