Re: WebDAV Bindings - Issue Yaron.AtomicDelete

   From: "Roy T. Fielding" <fielding@kiwi.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?

I like Judy's two paragraphs, so that's fine with me.

Just for interests sake, since my rewording was intended to be just
state the key point from Judy's two paragraphs, what was wrong with
it?  Doesn't a protocol always defines requirements on the
implementation?  (I'm not disagreeing with you, I just didn't
understand your point.)

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

I agree.  The term "atomicity" should not be used in this context.

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

Good point.  An appropriate error status should be defined.

Cheers,
Geoff

Received on Thursday, 27 January 2000 14:14:52 UTC