Re: Simplifying RFC-2518 Locking: A proposal

---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 10/15/99 03:32 PM
---------------------------


Jim Amsden
10/15/99 03:28 PM

To:   "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
cc:

Subject:  Re: Simplifying RFC-2518 Locking: A proposal  (Document link: Jim
      Amsden)

I'm all for it.

You also loose the ability to reserve a name in the namespace by locking a
resource that doesn't exist. (Boy when you say it that way, it really doesn't
make sense).

I would resist the second extension. My server currently does not associate
anything with the lock token except the locked resource. In particular, it
doesn't remember the URL used to lock the resource, and there is no special case
URL mapping that would somehow add lock tokens to namespace resolution
calculations, some of which happen outside my server's domain. It seems like if
we have to do this, we're still missing something. I think the solution is that
if the user is conserned about someone moving his locked resource, then he
should lock the parent collection. That's what locking collections is for, to
control the namespace. Alternatively, we can fail any move whose souce is
locked, and the requesting principal either doesn't own the lock, or didn't
specify the lock token. The confusion here is that PUT and DELETE are resource
methods that effect their parent collection as a side effect. It would be better
to have some addMember/removeMember methods on a collection to do this. The
problems result form the behavior being in the wrong place. But this is
inherited from HTTP which didn't have collections, so we'll have to work around
it.

Now, while we're on a role, how about getting rid of those pesky lock tokens!
The only thing they seem to do is let a particular principle who is running
concurrent authoring applications that might be updating the same resources
detect the possibility of overwrite conflicts by distinguishing which
application got the lock token by doing the LOCK, and which one got it from some
other mechanism (like IPC or the user typed it in). The application that
directly got the lock could proceed with its operation while the others could
put up a warning indicating there might be some other application that could be
updating the resource at the same time, and you might want to think about
whether you want to do this operation now or not. (Now there's a warning for
you). It took me quite a while to figure this out, and I may not have it right
yet, but that's my interpretation of the spec. Note that clients don't have to
do anything with the lock token except hang on to them and send them back when
needed. The above is just a suggested convention. Not also that having a lock
token doesn't give any other principle any privilege as you must own a lock
token to be able to use it. I submit the problem being solved is not worth the
protocol complexity and client inconvence (having to retain all those lock
tokens). Note also that other systems either associate the lock with the process
id (which we can't do in an HTTP server), or let the user be responsible for
concurrent process he might have started up. I'd be happy that.





"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 10/15/99 01:48:45 PM

To:   w3c-dist-auth@w3.org
cc:

Subject:  Simplifying RFC-2518 Locking: A proposal




Encouraged by some degree of enthusiasm expressed on this list for
simplifying RFC-2518 locking, I've modified my earlier non-proposal in
light of the recent discussions on the mailing list, and now have a
real "proposal" to make.

**********

A LOCK/UNLOCK request without a depth header places/removes a lock on
exactly one resource (the resource identified by the request-URL).  A
LOCK/UNLOCK request on a URL that is not mapped to a resource will
fail with a 404.  You can use a depth header to place/remove locks on
a collection and its members at the time of the lock.  This
placement/removal of locks MUST be performed atomically, or the LOCK request
MUST fail.

Only an explicit LOCK request ever adds a lock to a resource, and only
an explicit UNLOCK request ever removes a lock from a resource.  In
particular, locks are not deleted as a side effect of a MOVE or a
DELETE, and locks are not added as a side effect of a MOVE due to
"inheriting a lock" from a collection.

A request fails with a 423 if the request would modify the state of a
write-locked resource for which you don't hold the lock token.  The
state of a basic resource is its body and its dead properties.  The
state of a collection is its set of bindings and its dead properties.
A write-lock request on a resource that is already write-locked will
fail with a 423.

**********

And that's it.  This does lose some functionality.  It doesn't guarantee
that your handle on a locked resource will always be valid, and it doesn't
allow you to "add a resource" to a lock.  If one or both of these
are considered essential, I would be willing (but not happy :-) to add
one or both of the following extensions:

A Lock-Token header containing a lock token returned by a prior LOCK
request can be included in a subsequent LOCK request to extend an
existing LOCK.  A server may fail this request if the specified
lock token cannot be extended to the specified resource.

A Lock-Token header may be included in any request, which
will cause the request-URL to identify the resource that was identified
by that URL at the time it was locked with that lock token.

**********

I'll know Yaron is back from traveling when my in-box suddenly
bursts into flames before my eyes (:-).

Cheers,
Geoff

Received on Friday, 15 October 1999 15:35:49 UTC