UNLOCKING, was Bindings, Locks and MOVE's

<gs>
This whole thread (post-Judy's message) seems to be picking out a very
minor detail of her post. Personally, I find this nit-picking of detail
counter to the goal of her original post: "test its conclusions with the
mailing list members."
</gs>
Sorry Greg.  I'm basically in agreement with testing the conclusions, I was just
pointing out one place where I as a member of the list feel that it's off the
mark.  I'm on the fence on most of the other stuff and want to hear more
opinions there without comment from me.  My "nit-picking" is not meant to be an
indictment of the whole proposal.

<gs>
The second "AGREED" portion does not make a whole lot of sense. The
commentary states that the position is too strong [because it might not
make sense with other types of locks]. Are there other locks out there?
</gs>
Not in the spec, but the issues list does hint at suggested approaches
which include other lock types.

<gs> Do people have concrete, useful examples? </gs>
With write locks, shared or exclusive, there is no way to protect a resource
without preventing others from protecting it.   If there were a "write-block"
lock which people usually would use in shared mode, that would be another type
of lock.  (I guess most people call these "read locks".)  I don't think the
example itself matters though and I don't want anyone to get hung up on it.  The
point is the spec provides for other lock types and my statement expresses the
opinion that the need to protect a URI goes beyond write locks and applies to
all locks.  At least as long as we use the lock URI as the sole means of
identifying a locked resource or unlocking it.  (The use of URI's need not be
necessary but other options haven't seriously been discussed.)


<gs>
I haven't heard of anything
besides a write-lock yet. Regardless, I think it should be enforced in
the spec that a write-lock MUST have guaranteed protection of the
Request-URI.
Put in some language that says other locks can define the
MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive
state: a write lock says that others cannot monkey with your URI.
</gs>
Sounds paletable.  We can speak of this on a case by case basis.  We just need
to not forget to specify it for each type of lock we devise.   I'd feel better
if we'd either solve the unlocking problem or just say upfront that all lock
URI's are protected.  If we solved that problem, I'd feel very comfortable
saying that we can define URI protection on a case by case (lcck-type by
lock-type) basis.

How can we solve it?  I can think of several options...
   1) One way would be to say that the URI of the unlock method is not relavent.
Only the provided lock token is relavent to the request.  The complication is
that the only way that we have to provide lock tokens right now is via the
"Lock-Token" header. And it is my understanding that that header always
implicitly or explicitly causes a check that the provided lock token applies to
the request URI or some explicitly specified URI.  Therefore, in a neat
implementation, the lock-token check might tend to be done before the server's
method specific code ever gets a chance to execute.
   1b) We could specify a different request header for specifying the locktoken
to be unlocked.  That new header would not involve checking if the lock token
applies to a known URI.
   2) We could say that a LOCK response provides a pseudo URI that we can use
for the UNLOCK request that remains in effect until LOCK goes away.  And of
course we'd try not to recycle those URI's too rapidly.
   2b) We could have the lock request provide a pseudo URI like (2), but this
URI would be a URI that essentially specifies the GUID for the resource that was
locked.  The approach of course is dependent on us not defining any semantics
where the root of a lock can drift to another resource.  (No null lock reources
for example.)
   3) We could say that the lock token itself can be specified as the URI of the
unlock request.  This sounds weird and also seems to preclude the possibility of
unlocking multiple locks at once.  (The current spec is unclear on this
capability.)

My preference is (1b).

Once we do this, I think we'll have more flexibility to say if a given lock will
protect a URI.   Then I'd feel very comfortable with your recommendation of just
saying that *write* locks protect the lock URI.

Cheers, J.

Received on Thursday, 9 September 1999 21:56:50 UTC