W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

Is this LOCK model correct?

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Thu, 21 Jun 2001 15:43:17 +1000
To: w3c-dist-auth@w3.org
Message-ID: <20010621154317.K28868@io.mds.rmit.edu.au>
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.

Received on Thursday, 21 June 2001 01:44:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC