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