Subject: Re: Write Locks on Collections

From: [email-masked]
Date: Wed, 24 Nov 1999 08:30:58 -0500

Just in case you were looking for consensus, I agree with Greg.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Wed, 24 Nov 1999 09:33:09 -0500

>   If a lock owner causes the URI of a resource to be added as an
internal
  >   member URI of a locked collection then the new resource MUST be
  >   automatically added to the lock.
  >
  >I believe this statement should only apply to non-Depth:0 locks.
  >Otherwise, this results in the inability to independently lock
  >a collection and members of the collection.
> How so?  please provide a sequence of operations that would be impossible
> under this interpretation.

This really sounds like you are misunderstanding us since it's difficult to
believe that you think a singleton lock could be inherited.  You do seem
to believe that it's not inherited on creation of the lock, only with
addition
of new members.

/a/b.html exists.

LOCK /a/ is invoked, depth:0

I think we agree that /a/ is locked and that /a/b.html is not.  And that
the lock on /a/ prevents anyone except the lock owner from changing
the membership of /a/.

Now the owner does a BIND to /a/c/ and adds a whole new
tree below /a/.  I think you're saying that despite the fact that /a/ is
only singleton (aka depth:0)
locked, the whole new tree should be added to
the lock.  IOW... /a/c/, /a/c/d.html, /a/c/s/t.html all become part of the
singleton lock.  I think the rest of us are expecting those resources not
to be added to the lock because we expect a singleton lock
to only lock one resource.  I think this is where the disagreement
or misunderstanding lies.

So what does it prevent?  It prevents adding /a/c/ without
locking /a/c/ and the rest of the tree.  And this might
prevent a BIND/MOVE if there is a incompatible lock within
that tree.

What does what you propose ENABLE?  It does enable a lock-null
like behavior without all the dissonance of a null resource and
without some of the disadvantages of the depth lock workaround that
some folks might use in the absense of lock null resource support.

My opinion, this is interesting and deserves further consideration, but it
can't *replace* the default notion that singleton locks only lock
a single resource.

---

From: [email-masked]
Date: Mon, 29 Nov 1999 09:55:42 -0500

I agree with everything below except the conclusion that depth:0 locks are
inherited. The behavior is determined  by the lock on the collection, not
any of its members. So for example, say you create a new member with PUT.
This will require the lock token for the collection as it is locked to
control its namespace. Now anyone can PUT to the new resource without any
lock token as no new member is created, and the new resource is not locked.
However, the lock token for the collection must be specified in order to
delete this, or any other resource from the collection as this is effecting
the collection's namespace. So in this sense, the behavior of the lock is
"inherited" by the new resource, but I wouldn't look at it this way. I
think this is just the meaning of a lock on a collection.

See details below in <jra> tags.

Jim Davis <[email-masked]> on 11/25/99 06:37:56 PM

To:   [email-masked]
cc:

Subject:  Re: Write Locks on Collections

At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote:
>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.

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?
<jra>
Agreed
</jra>

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?
<jra>
Yes because this is changing the collection's members or its managed
namespace.
</jra>

2) Previously exising members are not affected.  I can PUT or PROPPATCH to
them at my whim, right?
<jra>
Yes, you or anyone else subject to their own individual locks and access
controls of course.
</jra>

3) However, I can't DELETE them without the lock token, right?
<jra>
True, but this doesn't mean the lock in inherited. This is just the meaning
of a lock on a parent collection. You can't change the locked collection's
members without the lock token.
</jra>

So where we seem to disagree is:

If I add a new internal member, is it added to the lock, or not?
<jra>
Not added to the lock. You're confusing the notion of a lock on a resource
with the meaning of a lock on its parent collection.
</jra>

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.

with all best wishes

Jim