Comment 9 for bug 1503161

Bruno, what are you wanting to see?

The way things are now, DELETEs don't respect write affinity. This could be rephrased as "DELETEs assume they will be called more than <replication cycle time> after the initial PUT. We could have made the other choice: make DELETEs respect write affinity. However, this would mean that DELETE'ing longer-lived data (ie more than <replication cycle time> old) would get a 404 instead of a 204. In that balance, both options seem relatively equal in "rightness", but favoring longer-lived objects seems to likely impact fewer requests.

An alternative would be to always return 204 from the object server if a tombstone is written, since we *did* write a tombstone and it will be replicated out. Then the proxy would do quorum detection as normal. However, this would hide the "tried to delete a non-existant object" by returning 204 instead of 404.

We can't not write a tombstone if the .data file isn't found. There are many reasons that will happen in a normal cluster, and we need to ensure the delete action gets persisted. So there's a few options:

 * Leave it as-is, and know that with write-affinity you'll get more 404s on DELETEs than you may expect. Also, maybe turn off write-affinity.
 * Switch DELETE to use write-affinity and get more 404s on older data. Also, maybe turn off write-affinity.
 * Change the object server to always return 204 if the tombstone is written. This means that DELETEs to object that never were written will also give a 204 to the client.