- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Wed, 18 Aug 1999 16:26:35 -0400
- To: w3c-dist-auth@w3.org
<JC> ... The point is whether a LOCK that is rooted (singleton or not) at the destination URI survives. </JC> <gmc> I see at least two reasons in favor of deleting the lock: - A MOVE/COPY just does a regular delete (with deletion of all locks), rather than a "special delete" which deletes all locks except for the one rooted at the destination URI. - The MOVE/COPY protocol doesn't have to deal with the complexity of applying the old lock to the new resource. I can easily imagine the creation of certain types of locks that only apply to certain types of resources. The MOVE/COPY protocol would then have to deal with all the error conditions that LOCK has to deal with. One clearly can extend the protocol to answer these questions, but it makes for a significantly more complicated protocol. </gmc> <JC> ... The client simply declares if he wants to retain the lock or not when he issues the DELETE. Depending on the implementation, the server might even find it *easier* to support the keeping of the lock. (AKA no code at all.) <gmc/> A server has to delete all of the LOCK's rooted at descendents of the destination URI, so I don't see how it could be easier for it to delete all descendent locks, but not the lock at the URI. <JC> 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. ... <gmc/> I think this is better handled by just saying (as suggested by Yaron) that a COPY/MOVE should be performed atomically, and not bother with trying to use locking to achieve atomicity of COPY/MOVE. Cheers, Geoff
Received on Wednesday, 18 August 1999 16:26:38 UTC