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

David Binger wrote:
> Your storage is too smart for this StorageServer.

Teaching the StorageServer to take advantage of already coded mechanisms
like "sync" or "handle_invalid" should be a dozen lines of code :-).

The issue is that mechanisms are already there, sitting unused.

> Deleted objects are not the same as invalid objects.  I don't think
> it is the right choice to report them back in the same group.

I agree, I'm not sure either. In an ideal world, a deleted object should
be marked as such in clients and any access to it (read or write) or any
serialization of objects with references to marked-as-deleted objects
should take the programmer to outside and shot him/her in the head.

But my proposal is fairly simple to implement, and durus code already
has (minimal) support for that. Growing from that should be fairly trivial.

> The Durus StorageServer is not made for untrusted, badly behaved clients.
> That helps it to be reasonably simple.  This is not the only way that a
> hostile client could damage your stored data.  It could, for example,
> commit a reference to a Persistent instance that has never existed in the
> database at all.

I know that any durus client can corrupt the storage status or simply
erase all objects. I'm worried -nevertheless- about unintentional
errors, like keeping non persistent references around between transactions.

To allow that a programming error in a client leaves your storage with
dangling references or inconsistent state, when the mechanism to
detect/avoid it are simple and efficient is looking for unnecessary
headaches.

>> My idea would be to publish invalidations to ALL objects garbage
>> collected, to force them to ghost state (so, if your code touch them,
>> you will get a conflict, as should be) and all commits should be able to
>> raise "post conflicts" if a commited object has any link to a
>> nonexistent object.
>
> We could do this, but it would be complicated, and I think it would have
> no advantage at all for clients that do not hold and misuse references
> to transient objects across packs.

The price for a safety net :-). Performance should be unaffected, and I
would sleep better at night knowing that an innocent code error in a
client is not leaving my terabyte/a thousand million object storage dead
in the water.

As ever, I volunteer for the job, if you demand it.

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

iQCVAwUBRIYKuZlgi5GaxT1NAQK+xAP+L44YluiWg1tJgnxBQnO6lCQnF4DBJ+WM
ZYutYYSmbN+J4FWkMGIMsCtwUKJaUaXw/7hcF3ZKUAfM4KWClrH202zlR825TlIP
8gobpPxOCReZF9MwFmDGv05/TAl8SKbZ5rMzL8sqZ2muU68XDKXZe1lZK+kYs5AG
+pVjfZb/IMQ=
=OGlm
-----END PGP SIGNATURE-----