Re: WebDAV Bindings - Issue Yaron.AtomicDelete

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

In an implementation where only a single binding to a collection
is supported, then deleting a binding to a collection will result in all
the members of that collection being inaccessible, so having the server
traverse down and mangle all the subcollections is permissible (after all,
the client specifically said it isn't interested in any of them any more).

But in a system where having multiple bindings to collections is
supported (e.g. database and versioning systems), mangling member
collections as a side effect of a delete is unacceptable, since this
mangles resources whose current state may still be significant to the client.

One possible compromise would be to place this restriction only on servers
that support multiple bindings.  In particular, the phrasing could be:

The request "DELETE /pathX/resourceY" MUST remove the binding named
"resourceY" from the collection identified by "/pathX".  If a resource
supports the BIND operation, then the request "DELETE /pathX/resourceY"
MUST NOT remove a collection's binding to that resource unless
"/pathX" identifies that collection and "/pathX/resourceY" identifies
that resource.

Greg, Yaron, as supporters of the "mangle" form of DELETE (:-),
would you find this acceptable?

Cheers,
Geoff

   From: "Slein, Judith A" <JSlein@crt.xerox.com>

   I think maybe we haven't made it clear what we are trying to accomplish by
   saying that DELETE must be atomic.  And maybe expressing it that way is
   confusing.  Here are the results we want (I think):

   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:

   User UA uses URL /a/C/ to access collection coll1.  User UB uses URL /b/C/
   to access the same collection.  Now suppose UA issues a DELETE on /a/C/.
   What you want is for UB to be able to continue to use /b/C/ to access the
   collection (and all its descendents).  So you can't go deleting the bindings
   in coll1 to all its children.  All you want to do is remove the binding
   a:(C->coll1) from collection /a/.

   Does either of these restrictions cause problems for mod_dav?

Received on Thursday, 27 January 2000 12:56:46 UTC