- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 7 Mar 2003 09:57:50 +0100
- To: "Brian Korver" <briank@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Thursday, March 06, 2003 11:56 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > ... > > Julian, > > If it is the goal to have WebDAV implement the semantics of the > Unix API, then I would prefer that it more closely model those > semantics -- for instance by making DELETE fail on non-empty > collections. No, that's not the goal (at least I don't think so). > Personally, I don't think that WebDAV should implement the > semantics of the Unix API, at the very least because of > the overhead -- imagine having to issue a DELETE for every > resource in order to delete a collection containing a million Correct. The overhead my be ok in a local fs, probably is problematic with a network filesystem, and won't be acceptable for WebDAV. > files. I feel that WebDAV should implement semantics that > are closer to the Unix CLI, which of course was designed to > be easier on the fingers (read: "lower overhead") than > the API. Yes and no. I really think that there may be separate use case that require separate solutions. A client should be able to request a MOVE operation that will fail if the server can't support full MOVE semantics (for instance by changing the DAV:resource-id property). A client would then be able to reconsider, possibly issuing a COPY/DELETE sequence instead. Hopefully we can agree that this type of request should be supported. If we do, we're left with the alternatives of making this the standard behaviour for the RFC2518 MOVE, or to invent some new marshalling. I'd prefer the former, but I probably could live with the latter. A similar problem obviously exists with the DELETE collection atomicity issue. -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 7 March 2003 03:58:09 UTC