RE: GULP (version 5)

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote:

   > - If a collection has a direct depth:infinity lock with token X,
   > - all

   Actually it doesn't matter if it's direct or not in this
   sentence.... or is "members" a recursive term?

Yes, members is a recursive term ("internal member" is the
non-recursive term).

   >   members of that collection (other than the collection itself)
   >   will have an indirect depth:infinity lock with token X.  In
   >   particular, if a binding to a resource is added to a collection
   >   with a depth:infinity lock with token X, and if the resource
   >   does not have a lock with token X, then an indirect lock with
   >   token X is added to the resource.  Conversely, if a resource
   >   has an indirect lock with token X, and if the result of
   >   removing a binding to the resource is that the resource is no
   >   longer a member of the collection with the direct lock with
   >   token X, then the lock with token X is removed from the
   >   resource.

   Again, it doesn't need to be direct at the parent, just the ancestor
   unless "members" is recursive.

Think about recursive bindings, where A is locked and A contains
a binding to B, B contains a binding to C, and C contains a binding
to B. If you remove the binding in A to B, you don't want B or
C to continue being locked (gotta handle those edge cases :-).

   > - An UNLOCK request removes all locks (both direct and indirect)
   > that have the lock token specified in the Lock-Token header of
   > the request.

   >   The request-URL of the request MUST identify a resource that
   >   has a lock (either direct or indirect) with the specified lock
   >   token.

   I am uncomfortable refering to multiple locks.  I've always thought
   of it as one lock that affects multiple resources.  I'm also
   uncomfortable saying a resource *has* as lock as opposed to saying
   it *is* locked.  But I have to admit that how you're saying it so
   far is very easy to understand.

I agree with you that we need to emphasize that a LOCK creates a
single lock that can protect the state of multiple resources.  I will
reword the proposal to do so.

   Do you want to say what happens if you lock an unmapped URL?

Yeah, I guess we should add that (:-).

    That leaves the issue of how much of the If header is evaluated.
    I'll start a seperate thread on that as Geoff requested.

Great!

Cheers,
Geoff