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

Re: WebDAV Bindings - Issue Yaron.AtomicDelete

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Thu, 27 Jan 2000 10:35:02 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
Message-ID: <200001271035.aa07327@gremlin-relay.ics.uci.edu>
In message <10001271756.AA29444@tantalum>, "Geoffrey M. Clemm" writes:
>I agree with Judy's description of what we want to achieve by saying
>DELETE is atomic.  Another way of phrasing it is that avoids the word
>"atomic" is to say:
>"A DELETE modifies the state of the collection resource containing the
>specified binding (namely, by deleting that binding), but MUST NOT
>modify the state of any other collection resource as a side effect."

No, that is a requirement on the implementation, not the protocol.
Why don't you just use the two paragraphs that Judy listed?

>>1. DELETE removes a single binding.  It does not remove all the bindings to
>>a resource, only the one identified by the Request-URI.  If it happens to be
>>the last binding, then what happens about garbage collection of either
>>content or properties is outside the scope of the spec.  DELETE is just
>>about removing the binding.
>>2. In the case where the binding is to a collection, DELETE still means only
>>remove the binding to that collection.  It is not acceptable to walk the
>>tree deleting bindings to descendents of that collection.  This would have
>>disastrous consequences in an environment with multiple bindings to
>>resources.  To resurrect an example of Jason's:

This has nothing to do with "atomicity".   It does, however, raise a
problem in that removing the last binding to a non-empty collection might
be unacceptable to the server.  This second case should allow the server
to report an informative error if it requires that the collection be
empty first (this would depend on the nature of the colection resource,
not on some aspect of the protocol).

Received on Thursday, 27 January 2000 13:35:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC