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

What about this model with respect to DELETE and bindings? Rough
specification-like language follows...

---
When a client issues a DELETE request to a collection that has internal
bindings, the preferred server behavior is naturally to achieve a
complete success, whenever possible.  However, servers may behave
differently depending on what bindings exist in the rest of the system.
The collection being deleted may contain the last bindings to one or
more resources. When the last binding to a resource is deleted, the
server may be implemented to perform some cleanup (e.g. release tied-up
storage resources).  If the server is unable to complete its cleanup,
the server MAY do an incomplete recursive delete operation, leaving some
resources behind. The server MAY leave parent collections of undeletable
bindings/resources in place in order to preserve a consistent URL
namespace -- this is equivalent to the behavior specified in RFC2518
[section ref].  The benefit of maintaining a consistent namespace, to a
server implementation, is that orphaned resources remain findable by
clients, so that clients can take actions like changing permissions or
removing locks and finish their DELETE operation.  In case of a partial
DELETE success, the server MUST report individual undeleted
bindings/resources, URL by URL, using the multi-status response body.

 At the other extreme, a DELETE request to a collection may be as simple
as an atomic unbind, which is clearly preferable because to the client's
point of view this is a complete success.

---
Lisa


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Friday, March 07, 2003 6:09 PM
> To: 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
> 
> 
> 
>    From: Brian Korver [mailto:briank@xythos.com]
> 
>    Other than loops, what are the problems unique to multiple
>    bindings and partial MOVE?
> 
> One example was posted in the message below:
> 
>    From:	Clemm, Geoff [gclemm@Rational.Com]
>    Sent:	Monday, March 03, 2003 6:34 PM
>    Subject:	RE: Move and Delete (was: bind draft issues)
> 
>    ...
>    because it can cause a DELETE in one collection to cause a change
>    in another collection, and this kind of "deletion side effect"
>    was something we explicitly were trying to avoid.  For example,
>    suppose /henry/has-friend/jeff and /jim/has-friend/jeff
>    were bindings to the same collection, JEFF, and JEFF has a binding
>    named "wife" to a resource, MARI.  Now suppose henry gets mad
>    at jeff, and issues a "DELETE /henry/has-friend/jeff" request.
>    But suppose at that moment someone else has a Depth:0 lock
>    on the /henry/has-friend collection.  The result of a "best effort"
>    deletion is the removal of the "wife" binding from JEFF.  That
>    may be OK if you were just updating the information accessible
>    from /henry (he isn't JEFF's friend anymore, and he's happy to
>    purge as much information about JEFF as he can), but with multiple
>    bindings, "best effort" deletion has now trashed the JEFF object
>    in all the other contexts in which it is still visible (and the
>    folks that still are his friends are still interested in that
>    information).
> 
>    So we're not saying that "best effort deletion" is always 
> a bad thing,
>    but we are saying that "best effort deletion" is a bad thing when
>    you care about multiple bindings to the same resource.
> 
>

Received on Saturday, 8 March 2003 13:44:19 UTC