- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Mar 2003 01:27:36 +0100
- To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "Julian Reschke WebDAV" <w3c-dist-auth@w3.org>
> From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 1:02 AM > To: Julian Reschke > Cc: Clemm, Geoff; Julian Reschke WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > On Tuesday, 03/04/2003 at 04:47 CET, "Julian Reschke" > <nnjulian.reschke___at___gmx.de@smallcue.com> wrote: > > > Saying that it doesn't support atomic deletes doesn't make sense to > > > me. The concept doesn't exist. The binding spec's DELETE > command is > > > asking that only one thing be done. If you can't do that one thing > you > > > need > > > > And that's why we're discussing this right now. The BIND spec requires a > > very specific DELETE behaviour, and some people do not seem to find that > > acceptable. Therefore the need to come to a consensus. > > I've only heard that servers are forced in to this behavior, not that bind aware > clients actually want this behavior. I'm arguing that servers can support this at the > WebDAV level. And if they can't they need to reject the DELETE request reject > BIND's to collections, or not claim that they are supporting BIND > functionality. a) what if they want to just implement RFC2518's DELETE? b) how do I not claim to support BIND functionality, when indeed I *do* implement the BIND live properties and the BIND method? > ... > > > I would hope it's possible though and that you wouldn't have to reject the > > > request. Even in a file system based server, I'd hope that the server could > > > simply unmap the collection and then in the background do the delete/move > > > of the whole tree incrementally if that were appropriate. > > > > But what if this simply is not what the system *should* do? > > I did say that it can happen in the background. It doesn't have to. It can be > done in the foreground. Yes. However: this was true for RFC2518's DELETE, yet after very long discussion the spec ended up with a non-atomic DELETE. I think this was correct (if only for the reason that an atomic delete on a large namespace partition can generate a transaction that's simply too big to handle properly). It seems that this is an attempt to "fix" RFC2518's DELETE through the backdoor. If this is the case, this should be made clear so that everybody is aware of that. > But no one has argued that they want partial results appearing as a result of a DELETE > in the presence of bindings. What they have argued is that that servers are forced to leave I do. > partial results. I have shown that in the situations mentioned, they are not forced to leave > partial results. > > But doing what I suggest is not the only acceptable approach. Server implementations can > claim not to support bindings, > reject BIND requests to collections, or reject DELETE requests that they aren't sure they can > complete. But they can't return partial deletion in the presences of multiple bindings. Again, the issue is NOT a DELETE in the presence of *multiple* bindings to a collection. The issue is a DELETE to a collection through it's only binding, which RFC2518 allows to be non-atomic, while the BIND draft requires it to be atomic. I think that's inacceptable. > > > But if it can't, IMO it needs to reject the request. > > > > It may not be able to reject the request until after it has started removing > > resources. There's a reason why DELETE isn't atomic in RFC2518. > > See the rest of my posting. You probably can detect if you will not be able to complete > the operation. If the MOVE completes, you have completed the > request. If it MOVE is different because it is just a namespace operation. DELETE may (may!) also destroy resources. > fails, you have not. This does not leave partial results. What you will still need > to do is clean up symbolic references.in to the tree. This might be possible to > do in a simple remapping request or you can do it iteratively... or both ways. This > can be done in a way that makes it unnecessary to have to return partial results. > Finally... the server probably will want to reclaim (perhaps only in the > absense of versioning) inaccessable resources. But that problem doesn't change the > semantics of the WebDAV operation. If it needs to do that, it can do that in the > foreground before completion (as it would have had to do anyway) or in the > background, but it doesn't effect what the UNBIND/DELETE method should return > to the client. So again: why is RFC2518's DELETE non-atomic? (I guess the answer is in the WebDAV Book Of Why). -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 19:28:11 UTC