RE: Simplifying RFC-2518 Locking: A proposal

Jim Amsden writes:
> Now, while we're on a role, how about getting rid of those pesky
> lock tokens!

... and while we're at it, let's break the majority of existing WebDAV
clients.

For example, if lock-tokens were removed from the spec., existing clients
that request a lock will be surprised when they do not receive a lock token
back in the response, and will flag an error.

> 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.

This is the rationale for this feature.

> I submit the problem being solved is not worth the
> protocol complexity and client inconvence (having to retain all those lock
> tokens).

You may be right. But, at this point, more interoperability problems would
be introduced by "fixing" this problem than would be removed by removing
lock tokens.  As your implementation experience shows, client-side handling
of lock tokens is simply tedious, and isn't a show-stopper.  Given a
tradeoff between potentially show-stopping interoperability problems with
existing clients (removing lock tokens from 2518), and a non-show-stopping
programming tedium (keeping things as is), I'm very much in favor of the
status quo.

- Jim

Received on Sunday, 17 October 1999 20:13:59 UTC