Re: Write Locks on Collections

At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote:
>   How so?  please provide a sequence of operations that would be
impossible
>   under this interpretation.
>
>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.

> But that's not what I asked about, or at least not what I thought I asked
> about.

But that's what it sounded like you were asking about.  That's why
I think we have a misunderstanding....



   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?
Ummm.  We agree that a token is needed to add to the collection, but we
need to define "added".  The new resource isn't "added" to the
lock, but it's membership is protected by the lock.  It's the difference
between a binding to a resource... and the resource itself.  More in a
sec...



   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?

   2) Previously exising members are not affected.  I can PUT or PROPPATCH
to
   them at my whim, right?

   3) However, I can't DELETE them without the lock token, right?
Yup, yup, yup.



   So where we seem to disagree is:

   If I add a new internal member, is it added to the lock, or not?

   I interpret 7.5 as saying Yes.  You seem to think that the answer is, or
   should be, no.

Yes, I think this it's just a matter of the definition of "added".  I
suspect we actually agree on the semantics.  More in a sec...


   Can you please explain this?  I don't see how this depth 0 lock would
   prevent anyone from updating the state of existing members.

And we don't think it would.  That's why I think this is just a
misunderstanding.  We basically agree with everything except for the
phrase "is added to the lock"... or it might actually be with the
definition of "internal member".  I'm actually vague on that term.
If it means binding, then I agree with you.

The child resource isn't added to the lock... but the binding to the
child resource is added to the state of the collection, so is therefore
locked with the rest of the collection's state and could be said to have
been added to the lock.

That means if

/a/b.html

exists.  And someone locks /a/ with depth:0, B can still be modified by
PUT and PROPPATCH.  It can't be MOVE'd, DELETE'd, or overwriten in a
fashion that destroys it's binding.

Now if the lock owner does the PUT that you mentioned on /a/c.html
and provides the token, then a new resource is created.  Anyone
can modify that resource (PUT/PROPPATCH), but only the lock owner
can DELETE it or MOVE it or in any way break the binding to it from
the /a/ collection.

We don't say that /a/c.html is locked or at least not the resource
at that URI.  You could say that the binding from /a/ to the /a/c.html
is locked.  And depending on our definitions of "internal member" we
might actually be able to say that the internal member was added to
the lock.

We should probably more clearly define "internal member"... or get
rid of the term.

J.

Received on Friday, 26 November 1999 14:36:46 UTC