RE: Locking, moving and deleting

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   On Behalf Of Clemm, Geoff
   > The best way to explain the defined MOVE semantics for a LOCK
   > is to say that a LOCK is on a URL, but that it is deleted
   > when the resource mapped to that URL is deleted.

   So far I can follow; it's not a bad model.  I'd append "or moved"
   to the end; most people will consider this different than "deleted"
   because we have different methods for MOVE and DELETE.

I agree that is worth making explicit to avoid any confusion.

   I don't follow your example as well (reproduced below) because WebDAV
   doesn't specifically allow for one resource to be mapped by several URLs.

WebDAV allows for one resource to be mapped to multiple
URL's because HTTP specifically allows for one resource to be mapped
to multiple URL's.  In particular, section 9.6 of RFC 2616:

 "A single resource MAY be identified by many different URIs. For
 example, an article might have a URI for identifying "the current
 version" which is separate from the URI identifying each particular
 version."

Therefore the locking protocol (and the rest of WebDAV) must have
well defined behavior in those cases where multiple URL's do identify
the same resource.

   Let's keep it simple and assume that a WebDAV system only maps URLs to
   resources 1:1.

That's fine, but it is good to keep the multiple mapping scenario in
mind for when someone suggests a "simpler" model that does
not handle the multiple mapping scenario.

   That means that when a collection containing null resources is
   moved or is renamed, all the locks in the collection disappear, and
   the null resources must be cleaned up.  That seems contrary to what
   the users would like to see happen; that's the scenario that made
   me rethink the way this works.

The loss of the locks is inherent in a "lock is on the URL" model.
The reason the "lock is on the URL" model is superior to the
"lock is on the resource" model can be seen by looking at the two
cases for moving a locked resource.

- If the client holding the lock does the move, it can easily lock
the destination collection with a new depth lock, and then perform the
move (the resources will be captured by the new depth lock).

- If some other client not holding that lock does the move (if it is a
shared lock, for example), there often is no good way for
for the client to "find" the resource after it has been moved (since
all the client has is a URL and a lock token).  While we were debating
this a while back, several vendors objected to the proposal that we
require a server to allow a client to easily find a locked resource by using
the lock token (PROPFIND Depth:Infinity on "/" is not considered a
good way :-).

Also, note that the current proposal for LOCK'ing an unmapped resource
(i.e. creating a real resource there) would leave those empty resources in
place to be captured by the depth lock at the destination.

Cheers,
Geoff

Received on Sunday, 30 September 2001 01:25:00 UTC