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

Re: Write Locks on Collections

From: <ccjason@us.ibm.com>
Date: Wed, 24 Nov 1999 09:33:09 -0500
To: Jim Davis <jrd3@alum.mit.edu>, w3c-dist-auth@w3.org
Message-ID: <85256833.004FE8AE.00@D51MTA03.pok.ibm.com>

  >   If a lock owner causes the URI of a resource to be added as an
  >   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
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.

Phone: 914-784-7569,   ccjason@us.ibm.com
Received on Wednesday, 24 November 1999 09:33:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC