Re: WebDAV Bindings - Issue Yaron.AtomicDelete

On Tue, 18 Jan 2000 ccjason@us.ibm.com wrote:
>...
> >>
>  There are, I freely admit, circumstances in which a client MUST be able to
> ensure that a DELETE is issued atomically. Clients in those cases will have
> to choose to not interoperate with many WebDAV servers in order to gain
> atomic delete.
> >>
> These clients can interoperate with an old iterative server just fine if
> they also include 2518 support.  That's their choice.
> 
> We have asked around and it seems that server authors appreciate and are
> willing to comply with semantic of an "atomic" removal of a single binding.

I don't recall being asked, nor agreeing with atomic operations. If that
binding happens to be a collection, then it will definitely be non-atomic.

[ also assuming this is the "final" removal of the collection ]

>...
> >>
> Let me clarify that DELETE was defined to not be atomic with malice of fore
> thought. The non-atomic delete language was the result of nearly three
> years of negotiations and represented a deep and broad consensus built up
> amongst a huge community. Might I respectfully suggest to the BIND authors
> that they should not be so ready to overthrow years of careful consensus
> building.
> >>
> We've asked around.  Folks appreciate this behavior and are willing to
> support it.

Again: I don't remember being asked. Maybe I missed a post to this list?

Regardless, I am not willing support atomic deletions of collections OR
single, member resources. Note that I mentioned member resources here. I
delete a member resource in two steps: the contents and its properties.
Definitely non-atomic.

And with respect to the Apache web server, I will not even begin to think
of making it atomic (e.g. serialize all requests while a resource is being
deleted).

> >>
> Do not imagine that the lack of screaming on this issue reflects consensus.
> Rather it reflects the fact that most of the WebDAV community is too busy
> implementing RFC 2518 to pay much attention to BIND. The BIND
> functionality, while I believe it will be important to WebDAV, is a bit
> ahead of the majority of implementers so they just aren't reading or
> reviewing it, yet.
> >>
> We have asked around and we didn't accept silence as a response.

I was certainly silent. Either that, or I'm going senile and forget
responding to a question of atomicity. I certainly can't imagine replying
"sure, I can sure an atomic delete".

> >>
> The key reason DELETE was not allowed to be atomic (which certainly would
> have been a nice thing to be able to do) has to do with the way file
> systems work. Most file systems do not support depth operations atomically.
> So, for example, when you delete a directory what actually happens is that
> the program does a depth first walk of the directory tree and deletes all
> the individual files, walking backwards up the tree until finally deleting
> the parent directory.
> >>
> You've pointed out that this is a problem on your file system.  We've found
> no other.   We've tested it and our testing indicates that the MOVE option
> you mention below works.  (We did not test with ACL's though... or multiple
> bindings.)    We've also contacted folks at your organization and they
> didn't see a problem.

This is an undue complication: generate a unique name, rename the resource
to that new name, then process its removal. And again, mod_dav couldn't
even do this because of its separation between properties and contents: I
could move the contents away, but a PROPFIND could still return
properties.

>...
> >>
> There is then the third and final issue, WebDAV begins with a "D" for a
> reason. It's goal is to be distributed. Requiring atomic DELETEs would
> essentially hinder all but the most expensive of systems from being able to
> implement distributed namespaces across multiple physical servers. The
> reason being that the atomic requirement means that these systems will have
> to establish transactioning systems between themselves in order to issue
> DELETEs if they share namespace.
> >>
> It's only one binding.  The goal isn't to be atomic, that's just a
> fortunate side effect.

It is *definitely* not a "side effect." mod_dav certainly does not do a
rename-then-delete. Therefore, I have to take explicit actions to achieve
that behavior. I don't even think that I could *ever* guarantee an atomic
DELETE operation.

>...
> >>
> As such I move that the atomic DELETE language be struck from the BIND spec
> on the grounds that it destroys interoperability, requires behavior that
> would preclude file system based systems from supporting WebDAV and
> significantly increases the cost of implementing WebDAV in a distributed
> manner.
> >>

I agree with Yaron on this one. Strongly.

> I believe I've addressed all of these above.
> 
> It is very clear that DELETE should not be iterative or accept partial
> results in a server that supports multiple bindings.

I think it is very clear that it shouldn't.

Stating your opinion of clarity doesn't make it so, nor does mine. But I
certainly can tell you right now that I won't be one of the "example
implementations" required for an IETF Standard.

> Legacy clients may
> invoke DELETE without knowledge of the potential dangers.  Therefore, a
> simple DELETE should delete a single binding.  --- There is no compelling
> reason (so far) not to support single binding delete and it simplifies the

I believe that I've given you one. With a good chunk of extra work and
serialization within the server, then it might be possible. But I am not
really up for trying to figure it out.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 21 January 2000 17:31:02 UTC