Re: LOCK Scenarios

Judith,



> Two people have now taken a careful look at the lock / MOVE scenarios.
At least three people.  You overlooked my note.

<JS>
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.
<JS>
Agreed.  They seem consistant and your interpretation of what he's said sounds
right.  As my note pointed out, I think he had some trouble on whether lock
tokens are required though in scenarios 9/10.  It seemed to be based on his
assumption that changing the membership of a collection isn't an operation on
the collection.  Just on the resource already at the URI.  In subsequent notes
in response to Jim, Kevin seemed to recognize the role of the parent though.


<JS>
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.
</JS>
Just for the sake of consistancy,  I prefer the singleton and depth locks
to be treated the same.  Just as Kevin apparently does.

<JS>
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.
</JS>
I disagree somewhat with "it's the resource that gets locked" as sumarizing
Kevin's interpretation.  If the resouce moves and doesn't carry the lock with it
at times, then I don't think it's correct to say it's the resource that
is locked.  At least not without further explanation.  That's what my
note pointed out.  But yes, if a resource is locked at one mapping, it is
locked at all.  But only the original URI mapping is "protected"... using
the AdvColl definition of "protected".  At least that was my proposal... based
on AdvColl discussions.

J.

Received on Tuesday, 17 August 1999 11:42:02 UTC