W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

RE: GULP (version 5)

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 11 Oct 2002 09:19:47 -0400
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE2973DA2@SUS-MA1IT01>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
   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
Received on Friday, 11 October 2002 09:20:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:02 GMT