- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 10 Mar 2003 09:09:03 -0500
- To: w3c-dist-auth@w3.org
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