- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 13 Jul 2001 14:45:12 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
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