RE: LOCK Scenarios

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

<KW>  The resource /x/y/z.html has been deleted due to the move to /x/y,
therefore the lock there was removed.  This does lead to an interesting
situation where moving to /x/y can fail if you don't give the correct
lock-token to /x/y/z.html.  But I think this is a good thing.

Again I note that there is no good response to the move for failures during
the delete.

The argument on /x/y is open I believe

Obviously /x and /x/y are depth 0 locks otherwise they wouldn't have been
created due to the other locks in the system.

You don't need to give the lock-token for /x as its namespace is remaining
consistent.
</KW>
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>

<KW> Again /x/y/z.html is deleted so the lock MUST be removed</KW>

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

<KW> Again I believe this is consistent as descendents will be deleted and
therefore so will there locks...

I think we need to start again with the use cases from Judith.  There are
now a number more.  ccjason said a doc was being created.  If I don't see it
soon, I will create one.  I think all the use cases need to be looked at...

Again I think the major argument comes down to:
1) A lock locks a resource VRS
2) A lock locks the URL namespace

I'd like to vote we keep infinity locks, but my argument might start "It
took me a whole weekend to get that to work" :)

But there must have been reasons to put it in there in the first place.
Unfortunately I was not there for those conversations.
</KW>

Kevin

Received on Wednesday, 18 August 1999 19:31:47 UTC