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

From: [email-masked]
Date: Sat, 8 Mar 2003 19:25:56 +0100 (MET)

Hi,
I don't have time to follow the discussion in detail at the moment
but this post provokes a comment.
"Clemm, Geoff" <[email-masked]> wrote:
>    From: Brian Korver [mailto:[email-masked]]
> 
>    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 [[email-masked]]
>    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.
Goeff, 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.
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".
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.

Cheers, Edgar

-- 
[email-masked]                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/forum/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein

---

From: Jason Crawford <[email-masked]>
Date: Sun, 9 Mar 2003 12:47:56 -0500

> >    folks that still are his friends are still interested in that
What Geoff describes is very very very bad.  But I hope that even the
folks that can't implement atomic DELETE are not considering making
their incremental delete this broken.   Even if you can't implement
atomic delete, you still can't delete bindings that would still be
accessable after you did it atomically if you could.    If this prohibition
is
not clear from the spec, then the spec needs to be fixed.

> Goeff, I don't think your scenario is valid for our discussion.

I tend to agree, but it sounds like it might be for a different reason
than what I think you're saying below. (omitted)  My reason is mentioned
above.
It basically is that I think (hope) that no server is considering doing
what Geoff mentions and the non-atomic folks are only considering
something more benign if they can't do the DELETE atomicly.  I'm
hoping that the discussion is only "that more benign behavior" vs
"true atomic DELETE".

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Mar 2003 09:09:03 -0500

From: [email-masked] [mailto:[email-masked]]

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

"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