Re: LOCK Scenarios

It appears to me that Jim Amsden's intuition and the current wording of
the spec is more consistent than the "intended behavior".  In particular,
suppose you had three locks, on:

  /x
  /x/y
  /x/y/z.html

Now suppose you MOVE'd a new collection to /x/y.

I think we all agree that the lock on /x is unaffected.
But what about the locks on /x/y and /x/y/z.html?

It is consistent to say that all locks on deleted resources at
the destination are removed (i.e. consistent with the fact that
deleting a resource deletes its locks).

It is also consistent (although somewhat more complicated) to say
that the "delete" performed as a side effect of a MOVE is a special
kind of delete that does not remove locks.  But then neither the
lock on /x/y *nor* the lock on /x/y/z.html should be affected,
which means that if /x/y/z.html is not mapped to any resource
following the MOVE, then a lock-null resource must auto-magically
be created at /x/y/z.html after the MOVE.

In my opinion, the complexity of special casing delete for MOVE, and
creating these lock-null resources as a side effect of the MOVE,
significantly outweigh any benefits that might be achieved. 

Cheers,
Geoff

   From: "Slein, Judith A" <JSlein@crt.xerox.com>
   Date: Tue, 17 Aug 1999 10:46:15 -0400
   Mime-Version: 1.0
   X-Mailer: Internet Mail Service (5.5.2448.0)
	   charset="iso-8859-1"
   Resent-From: w3c-dist-auth@w3.org
   X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3159
   X-Loop: w3c-dist-auth@w3.org
   Sender: w3c-dist-auth-request@w3.org
   Resent-Sender: w3c-dist-auth-request@w3.org
   Precedence: list
   X-Lines: 42
   Content-Type: text/plain; charset="iso-8859-1"
   Content-Length: 1640

   Two people have now taken a careful look at the lock / MOVE scenarios.

   Kevin's intuitions are consistent: It is always the lock at the destination
   that survives after a MOVE, whether that lock is inherited from a collection
   or is directly on the resource at the destination.

   Jim Whitehead confirmed that this was the intended behavior specified in
   section 7.7 of rfc 2518.

   As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to
   contradict this, so the inconsistency in rfc 2518 needs to be straightened
   out.  Section 8.10.5 says that if Overwrite is "T", the resource at the
   destination will be deleted, and section 8.8.4 says that if a resource is
   deleted, all its locks are removed.  So the upshot seems to be that after
   the MOVE, any singleton lock at the destination will be gone.

   Jim Amsden's intuitions about the scenarios were different: No singleton
   lock ever survives a MOVE, but a resource that is moved into a locked
   collection does inherit the collection's lock.  So Jim's intuitions agree
   with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only
   about inheriting collection locks, and not about singleton locks.

   -------

   Cases 9 and 10 poke at the complexities added by multiple URI mappings to
   the same resource.

   Kevin's intuitions say that there is really no added difficulty about
   resolving these cases.  It's the resource that gets locked, as rfc 2518
   says, and it's still true that any lock, inherited or singleton, at the
   destination, survives the move.

   --Judy

Received on Tuesday, 17 August 1999 11:35:22 UTC