- From: Greg Stein <gstein@lyra.org>
- Date: Fri, 21 Jan 2000 14:35:39 -0800 (PST)
- To: ccjason@us.ibm.com
- cc: Yaron Goland <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
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