RE: is DELETE "best effort"?

I agree that there is an issue here that requires further clarification.

The key here is user expectation. When a user issues a DELETE they need to
know if the result is either going to be a best effort delete or an atomic
delete. They need to know this before they issue the command, without this
knowledge then they can never be sure what the result of the command is.

For example, imagine a program that can walk a tree of source code, change
all the ACLs so as not to give the current user write permission to those
files and then start to compile the source code into various bits and pieces
of code, inside the local collections, before linking them together. When
the final result is done the program will then issue a depth infinity DELETE
in order to clean up. Because the ACLs have been changed the program is
counting on the fact that the only thing that will be deleted will be the
code files. However in a world where best effort isn't guaranteed the
program's assumption can fail. The server may refuse the DELETE because it
can't successfully delete all the files atomically (due to the ACLs) 

This means, in practice, programs must ALWAYS assume the absence of best
effort. This means that WebDAV will be inefficient since clients will be
required to issue individual deletes for all possible files. 

The previous situation is the worst of both worlds. Clients that need
best-effort can't depend on getting it so they must do file by file deletes.
Additionally clients that really want atomic behavior can't depend on
getting it so they will also have to do file by file deletes, although they
could try a depth delete first and then follow up with file by file if there
was an error. The race conditions and performance problems introduced by
file by file deletes (even with pipelining) are unacceptable.

Therefore I believe that the best effort issue identifies an
interoperability problem with WebDAV. We need to either guarantee best
effort or guarantee atomicity. But the current situation in which it could
be either is just a mess.

For reasons that seem to have already gained consensus we can not mandate
atomic delete. Therefore we are left with mandating best effort. Those
clients who wish to guarantee atomic delete behavior will need to use the
MAN mechanism with the DELETE method.

Therefore I propose that when we rev WebDAV we put in language mandating
best effort deletes.

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thu, January 27, 2000 7:18 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: is DELETE "best effort"?
> 
> 
> 
>    From: Yaron Goland <yarong@Exchange.Microsoft.com>
> 
>    Bill the answer for RFC 2518 is an unequivocal YES.
> 
> What concerns me is that the sequence:
> 
> "Is DELETE best effort?  YES."
> 
> will result in people believing that DELETE *must* be best effort,
> i.e. a server is required to delete everything it can, even 
> if it actually
> knows (or could easily find out) that it cannot delete everything.
> 
>    What is being argued is if we should change that YES to a 
> no. This will
>    require issuing a new version of RFC 2518.
>    Until such a new version is issued the answer is YES.
> 
>    BTW, Geoff, RFC 2518 already supports having the server 
> refuse to change any
>    of the members if it can't delete the root.
> 
> I agree that this behavior is not forbidden by rfc2518, but I also 
> believe some implementors will misinterpret in one direction 
> (i.e. DELETE 
> must be all or nothing) or in the other direction (i.e. DELETE must
> be best effort), so whatever answer we arrive at, we should make sure
> it is clearly stated in the next rev of rfc2518.
> 
> Cheers,
> Geoff
>

Received on Monday, 31 January 2000 19:51:29 UTC