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

   From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

   I don't have time to follow the discussion in detail at the moment
   but this post provokes a comment.

   "Clemm, Geoff" <gclemm@rational.com> wrote:
   >    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.

   Geoff, I don't think your scenario is valid for our discussion.  If
   no lock had existed then all information would have been deleted.
   So for the folks that still are his friends JEFF/* would be
   "completely" trashed.

Not if DELETE were implemented as UNBIND.  The only thing the DELETE
would do would remove the binding named "jeff" from "/henry/has-friend".
All of the bindings in JEFF would remain untouched.  Since there are
still other bindings to JEFF, JEFF would not be garbage-collected,
and all of its bindings remain intact for use by those other bindings.

   Would have this have been a better or worse situation for them ?
   IMHO this usecase doesn't say anything about the "badness" of
   "best effort deletion".

"Best Effort" (probably better characterized as "worst effort" :-)
deletion, goes down trashing all the bindings in the collection
being deleted.  Whereas "unbind" deletion only affects the single
binding identified in the DELETE request, and leaves the others
untouched (although they could subsequently be garbage collected
if that was the last binding to those resources).

   Either jeff gives jim and henry the rights to delete JEFF/* even if
   it's shared, or he doesn't allow it. It's jeffs decision.

A client shouldn't have to count on locks and access control to
prevent it from trashing information by mistake that it didn't
intend to trash.

Note that as has been pointed out, if there is at most one binding
to every resource in the collection being deleted, it is fine to
trash all the bindings, because that is what the garbage collector
would have done anyway.

So we should revise the binding protocol to say that, i.e. that DELETE
should be UNBIND if their is a second binding to any resource in
the collection being deleted.

Cheers,
Geoff

Received on Monday, 10 March 2003 09:09:15 UTC