- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 21 Jun 2001 08:38:14 -0400
- To: w3c-dist-auth@w3.org
I totally agree. The only way to make sense of the 2518 locking semantics is to associate the lock with the URI. Then the *effect* of that URI lock is to restrict updates to the resource currently mapped to that URI, or in the case of a depth-N lock, any resource mapped to a URI that has the locked URI as a prefix, and has no more than N segments following that prefix. We then overload the DELETE and MOVE methods to not only unmap the resource at the specified URI, but also delete the lock associated with that URI (and all locks associated to an extension of that URI). We can use the shorthand "write-locked resource" to mean "a resource whose write access is limited by a lock", but the lock itself is on a URI, not a resource (which is why the lock does not move with the resource). A "lock-null resource" is a mechanism (hack :-) for exposing a lock when there is no resource currently mapped to a locked URI. Cheers, Geoff -----Original Message----- From: Alan Kent [mailto:ajk@mds.rmit.edu.au] Sent: Thursday, June 21, 2001 1:43 AM To: w3c-dist-auth@w3.org Subject: Is this LOCK model correct? I found a discussion of LOCK and BIND in the archives which helped a lot. But I still am trying to understand fully issues relating LOCK relating to depth "infinity". WebDAV talks about moving a resource under one locked collection to under another locked collection, and the old lock being lost and the new lock being gained. I am trying to get the semantic model in my head right. Comments on my model below would be appreciated. I am trying to work out if you do a LOCK with depth infinity, what is actually locked. Are the resources locked, or the URI's to the resources? My reading of various documents (including BIND stuff) indicates resources are locked, not URIs. However, the concept of LOCK with depth infinity is URI based. Moving a resource from under one infinity lock to under another does change the locks. But what if there is still a binding under the old tree to the resource, does it maintain its old lock? My guess is yes. Since some of the lock description is URI based, and other says resources are locked, I have come to the following model of locking. Please correct me if its wrong: - Locks are based on URIs. - A depth 0 lock puts a lock on that URI only. - A depth infinity lock identifies the leading path of a URI - any URI with additional path components is covered by the lock as well. - To check if a resource is locked, *all* of the URIs to the resource (if multiple bindings exist) must be checked against the locks that currently exist. In my understanding, locks are not really associated directly with resources because moving things to different URIs does not keep the lock. So the lock is not independent of the URI - hence locks are really best thought of as attached to URIs. Resources are locked if any of the URIs to the resource is locked. Alan
Received on Thursday, 21 June 2001 08:32:42 UTC