durusmail: durus-users: latency improvement in "new_oid"
latency improvement in "new_oid"
2006-05-16
2006-05-16
2006-05-16
2006-05-16
2006-05-17
2006-05-17
2006-05-17
2006-05-17
2006-05-18
2006-05-16
2006-05-16
2006-05-17
2006-05-17
2006-05-17
2006-05-17
2006-05-17
2006-05-17
2006-05-17
latency improvement in "new_oid"
Jesus Cea
2006-05-17
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

mario ruggier wrote:
> 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.

That is the point of a sparse, random and not predictible OID space. If
you have a 256 bit space for OIDs, trying OIDs at random will fails.
Data is statistically secure.

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

Your root object is not my root object. Each client can have its own
root object. I explain this in a message just sent.

Think about this:

1. If the OID space is sparse, you can only access objects following
links between persistent instances. Trying random "get(oid)" will fails.

2. You need a initial know OID to "bootstrap" your object graph. This
would be your "root" object.

3. Each user could have a different "root" object. So different object
graphs.

4. The "root" object to each "database/user/password" tuple could be
provided by the server when the user authenticates.

In any case, in my thinking of a "database/user/password" authentication
I rather prefer to keep each database separated to be able to impose
quotas, ease backups and provide security without touching Durus too
much. In fact the changes would be minimal, as I already proposed in
another email. More, I have already a working implementation in
production now :).

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

iQCVAwUBRGr9Lplgi5GaxT1NAQKOyAP7BLk9w69JF1TA5U/IwNFLYH7bKgE8ohib
lWDqdkIwJ73cXF6IINNaVQXZYqq22XaOcZt6O3tqNFekLLjAjMr+I1SJmq/4nDXV
YchSPVQ2rcB3QBp1uFRi6D769RSmFbjNNs3H5iKI5mrljgMFo1pXHvZ8AE30JBI+
NJI74S4F9iY=
=I8O7
-----END PGP SIGNATURE-----
reply