RE: Is this LOCK model correct?

   From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]

   RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs"
   and "LOCK request on a resource MUST NOT succeed if can not be
   honored by all the URIs through which the resource is addressable."

   If you think about it, the first statement makes sense when you
   consider the second statement.
   However, I think the server applies locks to resources, but our
   visualisation is that locks apply to URIs.

Note: I will be arguing vigourously that we delete the "locks apply to
resource, not URIs" phrase from the next draft of 2518.  I believe
this statement has proven to be very confusing and misleading.
We should replace this with "a lock is on a URI, and a resource is
locked if it is mapped to a locked URI".

   > - A depth 0 lock puts a lock on that URI only.

   Depends on what you mean. A resource can have one or more URIs
   mapped to it (RFC 2518 sec 5.1). The resource would be locked and
   thus all the URIs that map to it. So no matter what URI (that was
   mapped to the resource) that was used by the client, the resource
   would appear to be locked as far as the client is
   concerned. However, none of the descendants would be locked.

Yes, you'd probably want to supplement this statement to make
sure it is not misunderstood.  Something like: "but the lock
controls access to that resource, even when that resource is
accessed through another URI".

   > - 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.

   As stated above, a resource MUST NOT be locked if the lock cannot
   be honored by all the URIs which address it. You shouldn't have an
   occurrence where a resource is locked, but using a URI that maps to
   it indicates the resource isn't lock. So in *theory*, you shouldn't
   have to check all the URIs because any of the URIs (that map to the
   locked resource) can be used to discover that the resource is
   indeed locked.

Yes, the protocol does require that all the locks that affect a
resource (from any URI) appear in the DAV:lockdiscovery property
of that resource, so you just need to look at that property.
Now an implementation may implement that property by a scan
against all locks that exist on a URL that is mapped to that
resource, but that's an implementation choice.

   > 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.

   Of course, its all a lot simpler if your server only supports one URI per
   resource. It makes the understanding of locking a lot easier :-)

Yes, 2518 largely ignores the use case where one resource is mapped
to multiple URI's (thus there was no BIND method, and
DAV:lockdiscovery did not expose the URI that was locked).  But we'll
fix all that in the upcoming new draft of 2518 (:-).

Cheers,
Geoff

Received on Saturday, 23 June 2001 23:18:55 UTC