RE: Is this LOCK model correct?

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