- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Wed, 15 Sep 1999 11:32:53 -0400
- To: "'Kevin Wiggen'" <wiggs@wiggenout.com>, ccjason@us.ibm.com, w3c-dist-auth@w3.org
I like everything that you say here, but the MOVE / COPY TO cases raise a red flag for me. We claim in the bindings spec that the MOVE semantics we present is equivalent to the COPY + fixup + DELETE semantics defined in RFC 2518. But I doubt it when I look at this case. Leave aside for a minute intuitions about what should really happen, and just see what would follow from the underlying semantic model: Suppose we define MOVE as "remove the binding identified by the Request-URI and add the binding identified by the Destination header". Now consider your case: /a/b.html and /x/y.html both point to resource R, and I have an exclusive write lock on /a/b.html. User2 tries to MOVE /c/d.html (which points to some other resource S) to /x/y.html. It seems this should be possible, because all that is happening is that the binding y.html in collection /x/ is being replaced with one that binds to a different resource. Nothing happens to resource R. But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would have to be duplicated, overwriting R. And this would not be allowed, because R is locked. Of course, we can legislate this problem away by, for example, accepting your proposal that a MOVE or COPY like this one fail no matter which semantics you use. But I'm afraid other cases will turn up that reveal inconsistencies between the 2 models of MOVE. --Judy > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Wednesday, September 15, 1999 1:01 AM > To: ccjason@us.ibm.com; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > Ahhh OK so I take back some of my last post. I am beginning > to see clearer > now. > > Correct me if I am wrong. > > /a/b.html and /x/y.html both point to resource R via BINDS. > > > 1) I take out an "Exclusive Write" lock L1 on /a/b.html. > Once this is > done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) > - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (LOCKED) > - can MOVE /x/y.html (will simply move the binding URI, resource not > changed) > - cannot LOCK /x/y.html OR /a/b.html (LOCKED) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination > resource is > LOCKED) Actually MOVE/COPY TO /x/y.html makes an interesting > point of do you > A) Do the delete first which UNBinds the resource and then > complete the > MOVE/COPY, or B) fail with resource LOCKED. I think you have to do B > otherwise you end up with 2 resources where you used to have 1. > > 2) I take out a "Depth-Infinity Exclusive Write" lock L2 on > /a. Once this > is done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) > - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (LOCKED) > - can MOVE /x/y.html (will simply move the binding URI, resource not > changed) > - cannot LOCK /x/y.html or /a/b.html (LOCKED) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination > resource is > LOCKED) > > 3) I take out a "Depth-Zero Exclusive Write" lock L3 on /a. > Once this is > done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (/a's namespace is LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - can PROPPATCH /a/b.html and /x/y.html (the resource is NOT Locked) > - can PUT /a/b.html and /x/y.html (the resource is NOT Locked) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (/a's namespace is LOCKED) > - can move /x/y.html (will simply move the binding URI, resource not > changed) > - can LOCK /x/y.html and /a/b.html (they are not Locked) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - can MOVE and COPY TO /x/y.html and /a/b.html (resource not locked) > > Is this correct?? > > Kevin >
Received on Wednesday, 15 September 1999 11:33:28 UTC