RE: LOCK Scenarios

<KW> In case 9 and 10 I had arguments that the resource R, and not the
namespace should be locked.  This contradicts infinity locks a little, as
they lose and gain members on movement in the namespace.  So I guess I am
saying locks should LOCK the resource, but should be namespace aware :)
</KW>
It took a while to read it all, but I think I agree with everything you
said for scenarios 1 - 8.  It's difficult to express succinctly.  I
think it is after we get some vocabulary.

Lets call the URI at which the LOCK was placed the "lock URI".

The LOCK URI has special properties.  First of all, it is "protected".  These
scenarios don't cover that prroperty, but the Adv. Collection spec does.  It
means that among other things, that it's parent nodes (Is that what we call
them?) can not go through name space manipulations that would cause the locked
URI to disappear.  That is...

   if /a/b/c is locked, then /a/'s 'b' binding is not allowed to change and to
therefore take the URI "/a/b/c" out  of existance.  I'll leave that fuzzy for
now.  If we dig further, I'm sure we can find some complications in there.  The
idea behind protection is that we protect the URI so that someone that doesn't
have a lock can't make the LOCK URI mapping go away.  The thinking is that we
are locking that URI because we're going to be using that URI to perform some
operation on the resource.  If some other principal can make that URI go away or
map to something else, then we aren't happy.  (A URI is our only way of address
resources right now.)

In addition, the lock binds most tightly to the LOCK URI.  Then secondarily to
the resource at the LOCK URI.  That means if you change the resource at that
URI, the new resource gets the lock that was set to the LOCK URI.  (This what
your scenarios seem to suggest and it sounds like it might be what users want.)

Next... if the lock has depth... various descendent (vocab?) URI's are locked.
(We need vocabulary to distinguish this "locked" from what we are talking about
at the LOCK URI.)   And the resources at those URI's are locked.

The fact that these resources are locked also means that they are locked if
accessed through other URI's too... but that those URI's aren't necessarily
"protected".

Yes, this is a totally fuzzy definition.  I'll come up with a detailed boring
one later if this one shows promise.  Anyway, I think this is the definition
that you used for scenarios 1-8.   Now let me move on to 9 and 10....

Firstly, unless I misunderstand you, I think I disagree with what you've said
above about 9 and 10.  This seems to be in disagreement with 1-8.  I believe
that in the first scenarios, the LOCK URI is the primary location of the lock...
not necessarily the resource at that URI.  (Yes, this is in conflict with what
we've been thinking with AdvCollections, but I want to run with your proposal
which you demonstrated with scenarios 1 - 8...)  The resource IS locked, but
only by virtue of it's current relationship to the LOCK URI.  The fact that the
resource is locked does mean it (the resource itself) is locked at other
mappings too.

<JS>
9. The source resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y.
</JS>
<KW> Since the resource R is locked, if the correct lock token for /c/d is
given (the lock token for the lock holding R), then the move occurs.  Since
/a/b still points to R, /x/y is still locked via /a's lock. </KW>

I agree.


<JS>
9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to
/x/y.
</JS>
<KW> Again the MOVE succeeds if the token for R is given, the resource is
still locked by /a/b </KW>

I don't see why a token is necessary.. Yes R is locked, but the move is an
operation on the state of it's parent, not it.  (I assume that /a/ and /c/
aren't the same resource.)  That means the /c/d URI is not protected.  The /a/b
URI is, but the MOVE isn't threatening that mapping.  -- Besides the token
issue, I agree.


<JS>
10. The destination resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z.
</JS>
<KW> If correct lock token for R is given (If header with a tagged list of
/y/z and the correct token) the move completes.  Since /w is locking the
resource R, it continues to do so </KW>

I disagree about the lock token for the same reason as above... unless we're
possibly talking about a depth lock token.  Let's first assume we're not.
Moving /a/b to /y/z is changing the state of the collections /a/ and /y/.  (At
least that's how we have been thinking about it in the AdvColl discussions.)
Since neither of them is locked, the lock is irrelevant in the example.    (BTW,
I assume /w/ and /y/ are not two mappings for the same collection.)

Now if it's a depth lock.... which I think you assumed... In that case, R is
locked by virtue of being accessable via /w/x.  But I assert that that lock
remains irrelevant.  When all the operations are through, resource R remains
accessible via /w/x  and R remains locked.  Nothing attempted threatens to break
the lock.  It just becomes accessible through different mappings, but the
mappings that were lost were not PROTECTED by that particular lock since the
LOCK URI was not involved.

I agree about everything else besides the token.


<JS>
10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to
/y/z.
</JS>
<KW> Given the correct lock tokens (See above), the move succeeds.  The lock
is then lost according to number 2 above.  Again I would argue that the lock
on /w/x would still be there with the same logic as in number 2 above </KW>

Once again, I say the lock tokens aren't relevant here.  Nor is the lock.  R
continues to exist.  It's state hasn't changed.  And the LOCK URI wasn't
threatend by the move.


11) - One thing I want to point out is a combination of 9 and 10.  Both the
source and the destination are locked.  By different locks.  Exclusive locks.
 /a/b and /c/d map to R.   /a/ is depth locked.
/x/ is depth locked.
move /c/d to /x/y

In all the similar cases above, I believe we said it succeeded.   But in this
combination, I believe it fails.  Why?  Because if it succeeded, R would be
accessable via /a/b  and /x/y.  but both /a/ and /x/ are depth locked.
Exclusively.  That means R somehow would have inherited two exclusive
locks..  That sounds like something we have to disallow.  :-)   (Well, maybe.
I'll make another post on a twist on this in a sec.)

Anyway, Kevin, I think you have a viable proposal.  I think most of us were
expecting a resource to be the primary holder of a lock.  That seems like
something that would be easy to understand and would seem like what one would
want on first blush.   But I think you've suggested is that what clients might
prefer is that the LOCK-URI own the lock... and whether a resource is locked is
determined if the resource that has a mapping the is or descends from that URI.
As resources are moved around they might be added or removed from the lock as
their mappings change.  And even the resource mapped to the LOCK-URI itself can
change... and thus be added or removed from the lock.

I think we should keep your proposal on the table.  And probably define it more
rigorously.

J.

Received on Friday, 13 August 1999 22:17:56 UTC