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

Re: Write Locks on Collections

From: Geoffrey Clemm <geoffrey.clemm@Rational.Com>
Date: Sun, 28 Nov 1999 13:40:36 -0500
Message-ID: <00bb01bf3a84$86115480$384413ac@lex.rational.com>
To: <w3c-dist-auth@w3.org>
I agree with everything Greg says in this message.

----- Original Message -----
From: Greg Stein <gstein@lyra.org>

> On Fri, 26 Nov 1999, Jim Davis wrote:
> >...
> > If I lock a collection with depth infinity lock, then create a new
> > interrnal member of that collection  (e.g. with PUT) I have to provide
the
> > lock token to do the PUT, and the new internal member is added to the
lock.
> >
> > We all agree on this, right?
>
> Yes.
>
> > Now  suppose the lock were depth 0 not depth infinity.
> >
> > 1) to add a new internal member, I still have to provide the lock
> > token, right?
>
> Right.
>
> > 2) Previously exising members are not affected.  I can PUT or PROPPATCH
to
> > them at my whim, right?
>
> Right.
>
> > 3) However, I can't DELETE them without the lock token, right?
>
> Right. You must supply the locktoken because you are altering the
> collection (on the theory that the set of names of internal members is
> part of its state).
>
> > So where we seem to disagree is:
> >
> > If I add a new internal member, is it added to the lock, or not?
>
> It is not.
>
> > I interpret 7.5 as saying Yes.  You seem to think that the answer is, or
> > should be, no.
> >
> > Can you please explain this?  I don't see how this depth 0 lock would
> > prevent anyone from updating the state of existing members.
>
> The depth:0 lock does not prevent people from updating existing members.
> It prevents you from altering the collections state: the set of names of
> internal members. Therefore, you cannot add or remove internal members.
> This means you must supply a locktoken with PUT, MKCOL, or a DELETE. Note
> that you shouldn't be able to create a locknull resource either(!) without
> supplying a locktoken.
>
Received on Monday, 29 November 1999 11:10:54 GMT

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