W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Move and Delete (was: bind draft issues)

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>
Message-ID: <JIEGINCHMLABHJBIGKBCKEFFGKAA.julian.reschke@gmx.de>

> 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

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
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC