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"
David Binger
2006-05-17
On May 17, 2006, at 6:26 AM, Jesus Cea wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Binger wrote:
>> But Mario is correct that knowledge that the oid of the
>> root is the critical shared secret between the client
>> and the server.
>
> All of this are linked with my request of a "database/user/passwd"
> authentication procedure. Suppose the server sends the "root" OID for
> that "database/user/passwd" tuple when the user authenticates. Each
> user
> could have a personal "root". Since the user could only access objects
> following links, you could share a single storage between different
> users, even if they are malicious. A user can't "guess" a valid OID
> for
> an object of other users.

It seems like a shame to force all of these apparently independent
databases
through global transaction arbitration.

>
>> Although I do think the idea is interesting,
>> I don't think the oid space should be made sparse
>> so that you can run a storage server on a public interface.
>> I don't think you should run a storage server on a public
>> interface.
>
> Aha! :). I, nevertheless, would like to offer object storage services
> for my clients, just like now I offer ZOPE space or MySQL capacity.

Maybe you should consider some higher level object storage application
that perhaps uses Durus as the next layer.  It would be a minimalist
variant
of ZOPE space.


reply