- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 4 Mar 2003 16:47:21 +0100
- To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "WebDAV" <w3c-dist-auth@w3.org>
> From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Tuesday, March 04, 2003 1:45 AM > To: Julian Reschke > Cc: Clemm, Geoff; WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > ... > > 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. > to reject the DELETE request. But leaving a partial tree there is not an > option because the method didn't ask you to delete those other bindings > and in fact might not want them to be deleted. Can you define how I can delete the binding a (a being a collection) without also deleting the binding a/b (when b is present in a)? > 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? > 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. -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 10:47:58 UTC