Re: LOCK Scenarios

I missed something in my previous response to Geoff's note...

<GC>
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.
</GC>
<JC>
In my previous response I voted against retaining a lock for /x/y/z.html.
One other thing I'd like to check...   Is it possible to do a MOVE
operation that replaces a binding to a collection with a binding to a
non-collection?  (This relates to your discussions with JimW over
/x/y/ and /x/y being interchangeable.)

If so...  there might not even be a collection at /x/y after the move
which makes keeping a null lock at /x/y/z.html even odder.  To date,
all null locks have had collection resources at their PARENT URI.

I'd vote that for now we limit the things so that the only lock that we'd
consider retaining is at the DELETE's request URI.  Any ancestor lock
will be retained.  Any descendent lock will not.

Note: all of our discussion retaining destination locks also applies
to an overwrit'ing BIND.
</JC>

Received on Tuesday, 17 August 1999 15:08:20 UTC