RE: are depth 0 locks inherited by newly created children?

Yes, I've been following this analysis too, and I concur that depth 0 locks
stay on the resource, period.  There should be no weird crossovers from
depth:0 to depth:1 just because the resource is a collection.

[I am afraid to ask what the implications are for creating a locked-null
resource as an immediate child, but if it is a problem, I think the defect
is in lock-null.]

-- Dennis

------------------
Dennis E. Hamilton
InfoNuovo
mailto:infonuovo@email.com
tel. +1-206-779-9430 (gsm)
fax. +1-425-793-0283
http://www.infonuovo.com

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey Clemm
Sent: Tuesday, November 30, 1999 10:27
To: w3c-dist-auth@w3.org
Subject: Re: are depth 0 locks inherited by newly created children?

[ ... ]

I lock a collection, because I'm going to be adding members
to that collection.  If a depth:0 lock applies to all the
immediate members of a collection as well, then I have prevented
anyone from updating the state of one of the existing internal members of
that collection.  If I'd wanted that behavior, I would have issued a
depth:1 lock.  And quoting from the definition of what depth means:

   The Depth header is used with methods executed on resources which
   could potentially have internal members to indicate whether the
   method is to be applied only to the resource ("Depth: 0"), to the
   resource and its immediate children, ("Depth: 1"), or the resource
   and all its progeny ("Depth: infinity").

Cheers,
Geoff

Received on Tuesday, 30 November 1999 17:44:39 UTC