RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Since somebody was asking if lock-null resources have been implemented:
    - Xythos WebFile Server implements lock-null resources
    - I believe the Microsoft DAV servers allow LOCK of a non-mapped URL
then
   PUT.  Their version of a lock null resource may not support MKCOL, and it
   may not disappear when the lock expires, but it still solves the
lost-update
   problem for a new resource (not a problem for MKCOL).
    - Our tests of Office XP show it seems to use lock null resources.

Note that the main issue is not whether anyone has implemented lock
null resources, but rather that different repositories have
implemented them differently because the current lock null semantics
are incompatible with the semantics of those repositories.
To me, this is a clear signal that lock null resources are not
a basis for interoperability.

   My next concern is that the functionality was intended to solve an
   important problem - the lost-update problem for a new resource is
   the problem that two users can both try to create a resource with
   the same name using PUT.  One overwrites the other unwittingly.

It has been demonstrated in the recent thread on lock null resources
that the lost-update problem for a new resource can be solved without
the use of lock-null resources.  In particular, you do a
PUT/If-None-Match with a zero length body, followed by a LOCK (or if you
wanted to create a collection, a MKCOL followed by a LOCK, or
if you wanted to create an activity, a MKACTIVITY followed by a LOCK,
etc.).

   LOCK already solves the lost-update
   problem for existing resources, so it seemed reasonable at the time to
use
   the same mechanism for new resources.

Yes, but there is no need for a lock-null resource.  You create an
"empty" resource at the location, which gives you a real resource to
lock, and then lock it (before you do any updates to that resource
that you care about).  The fact that another client can LOCK the new
empty resource is of no significance, since it does not have any of
the content that you care about yet (i.e. it is no different from them
getting their "lock" request in before yours).  If the server gives
the owner special permissions on the new resource, that is fine (and
only the creating client's LOCK will succeed), but it is not
necessary for solving the lost update to a new resource problem.

   Since lock null resources solve an important problem, and since
   they have been implemented, I'd object to removing them from
   RFC2518.  Although it may be possible to try to simplify, I'd
   hesitate.  We'd want to make sure there was a good reason to do
   that.  Is there any serious problem with the existing definition?

The current implementations have demonstrated that lock null resources
are not a basis for interoperability.  That is the serious problem
that is being addressed by removing them from the protocol.

Cheers,
Geoff

Received on Friday, 13 July 2001 14:37:50 UTC