Re: Locking URIs rather than Resources

     Now some locking questions. If LOCK applies to the name, not the
resource,
     /x/y.htm is locked, and /b/c.htm is bound to the same resource as
/x/y.htm,
     is /b/c.htm locked too? Probably not.

  Correct.  But modifying the resource identified by /b/c.htm does require
  the lock token for the /x/y.htm lock.  This does not make /b/c.htm
locked.

Geoff, you agreed that "/b/c.html" is not locked.  In this case I think
we'd
preferably say the "the resource at" either/both URI's is locked... but
only
one of those URI's is locked.   My point is that we should probably come up
clearer vocabulary/notation for making a distinction between the URI and
the resource.  For example, we used to say the URI was protected and/or the
resource was locked.
   ...

       What about LOCK  /b/c.htm?

   That is fine.

Hmmm.  Jim said they are the same resource.  I don't think he meant a
null-mapped
resource.  That being the case, I think you mean to say that the second
lock can
only be placed if it doesn't conflict with the lock already acting on the
resource
at that URI.  I think you must have assumed he meant a shared lock when you
said
that is fine.


   Not at all.  One user has /x/y.htm locked.  The other user has /b/c.htm
   locked.  That means you can't modify that resource unless you have both
   lock tokens.  In this model, a LOCK prevents a certain kind of change
   to something, but does *not* guarantee the ability to make such a
change,
   since other access rights or locks can come into play.

I agree with what you said about not guarantee'ing a right to change, but
what about requiring two tokens?  As far as I know, the situation you
outlined can only happen if  shared locks are used.   In that case, only
one lock token is required.

Received on Friday, 31 December 1999 18:22:21 UTC