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 first reason would not be significant if we added the
optional capability into DELETE that I suggested.  I pointed out
why it would be useful to add this capability to DELETE.

The second problem would also be possible if the parent of the destination
had a depth lock that was in conflict with the new resource(s) at the
destination. If such class of locks exist, then
the checking needs to be there anyway.  Just one more lock to
check.  (Similar argument to what you use below... except
supporting the opposite position.)
</jc>




   <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>Good point.  It's the nearly the same effort either way if there
are a lot of locks rooted below.  I wouldn't expect that to be common,
but who knows... And the server would have to search for them anyway.
That in itself could be relatively expensive depending on
implementation and size of tree.  Point well taken.
As I said, the proposal would be that it would have to be supported
either way though... so it was more importantly my point that it's
not much harder.  It's just the matter of optionally one less
deleted lock.
</JC>





   <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.
</gmc>
<JC>
This wouldn't be addressing the issue of atomicity of the COPY/MOVE...
although it would achieve that.  It would be addressing the atomicity
of the COPY/MOVE followed by something else if the client wanted it.
The same applies to DELETE.  There's something there you want to remove
and replace with something else.  The same applies to BIND with
overwrite... I think.  (See next note.)

This capability addresses the same
need that lock-null resources do now.  Without them, you'd have to
create the resource and then lock them and then do whatever else
you had in mind.  That's why I suggest that if we don't want this
capability, we have to wonder about lock-null resources.
</JC>

Received on Thursday, 19 August 1999 00:54:07 UTC