Subject: Re: LOCK Scenarios

From: [email-masked]
Date: Thu, 19 Aug 1999 00:52:27 -0400

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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 19 Aug 1999 10:03:39 -0400

From: [email-masked]

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

<gmc/> I agree that adding the capability to DELETE would be more
uniform than special-casing it for MOVE, but I'd prefer not having
it in either case (for simplicity).

<gmc/> I advocate removing "depth" locking from the spec
(in the "Locking: Implementation Considerations" thread)
for other reasons.

<gmc/> In general, I am against all bits of the
protocol which cause a lock to be "inherited", since this forces
all the "resource creation" methods to have to deal with all
the "LOCK" failure cases.  So I'm against:
- depth locking
- lock-null resources
- keeping the lock on the destination of a MOVE/COPY

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

I don't believe that LOCK's are a good technique for achieving
atomicity of an arbitrary set of operations following the COPY/MOVE.
The main problem is that a LOCK is a very coarse form of control, i.e.
none of the properties or bodies of any of the members of a depth infinity
lock can be modified by anyone.  In a distributed authoring context,
I believe an optimistic "modify/merge" paradigm scales much better.
As long as the MOVE/COPY operations are atomic, you can perform all your
changes in a personal copy, and then MOVE/COPY the result to its final
destination.

I agree, and am against lock-null resources.  I believe the
protocol could be simplified with very little loss of functionality
by just saying that if you want to achieve the effect of a lock-null
resource, you just create an empty resource (e.g. a resource with
an empty body) and then lock that real resource.

So to summarize, I'm in favor of:
- deleting lock-null resources from the spec
- deleting depth locking from the spec
- otherwise leaving alone the current wording in the spec
  of the effect of delete/move on locks

Cheers,
Geoff

---

From: Edgar Schwarz <[email-masked]>
Date: Tue, 24 Aug 1999 15:19:23 +0200 (MESZ)

> - keeping the lock on the destination of a MOVE/COPY
After coming back from my holidays and reading a lot of WebDAV articles
I don't want to repeat all arguments. I just want to say:
I agree with you :-)

Regards, Edgar

-- 
[email-masked] ON/EMS1, 07191/13-3382         Niklaus Wirth:
Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag.
Albert Einstein:  Mach es so einfach wie moeglich, aber nicht einfacher.