Re: LOCK Scenarios

   <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