W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: UNLOCK from the middle of a locked tree

From: <jamsden@us.ibm.com>
Date: Sat, 11 Mar 2000 12:11:14 -0500
To: w3c-dist-auth@w3.org
Message-ID: <8525689F.005E6C21.00@d54mta03.raleigh.ibm.com>




I didn't read the spec exactly this way. I considered depth locks a
convenience for setting many locks on the same resource using the same lock
token in a single request. Depth in all other methods applies to the target
resource and recursively all its children. It never applies to a parent of
the target.

DAV4J gives an error if you attempt to unlock a depth locked resource from
any resource but the one that was originally locked. It does this by
checking to see if the immediate parent of the target resource is locked
with the same lock token.
|------------------------+------------------------>
|                        |   Kevin Wiggen         |
|                        |   <wiggs@wiggenout.com>|
|                        |   Sent by:             |
|                        |   w3c-dist-auth-request|
|                        |   @w3.org              |
|                        |                        |
|                        |   03/10/2000 04:17 PM  |
|                        |                        |
|------------------------+------------------------>
  >------------------------|
  |                        |
  |           To:          |
  |   "Slein, Judith A"    |
  |   <JSlein@crt.xerox.com|
  |   >,                   |
  |   w3c-dist-auth@w3.org |
  |           cc:          |
  |   "Hall, Shaun"        |
  |   <Shaun.Hall@GBR.XEROX|
  |   .COM>                |
  |           Subject:     |
  |   RE: UNLOCK from the  |
  |   middle of a locked   |
  |   tree                 |
  >------------------------|









I think the spec is trying to state A.  In fact that is what Xythos does
(well we don't need to traverse hierarchies, but that's an implementation
point).

From anywhere in a depth lock, if you send a correct lock token with a
unlock request, the lock is removed, thus unlocking the entire tree.

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A
Sent: Friday, March 10, 2000 1:03 PM
To: 'w3c-dist-auth@w3.org'
Cc: Hall, Shaun
Subject: UNLOCK from the middle of a locked tree


I have this question from a product team in my company.  Any opinions?  I
would say that (b) is not an option, but failing the unlock request might
be.

--Judy

Section 8.11 UNLOCK Method. The first sentence states "...and all other
resources included in the lock". Does this mean that a client should only
Unlock from the point where the lock starts? For example, in a hierarchy:

                Collection 1
               |          |
           Collection 2        Collection 3
               |          |
           Resource 4        Resource 5

If the lock was created with a Depth of infinity on "Collection 1", should
the user only perform the UNLOCK on "Collection 1"?

We're concerned that a client may try and unlock from a sub-point within
the
hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence
in the RFC, we either:

a) Have to traverse the entire hierarchy (parents and all) removing the
lock
from all resources (in the above example, "Collection 1", "Collection 3"
and
"File 5").

b) Only remove the lock from "Collection 2" and "File 4".
Received on Saturday, 11 March 2000 12:11:40 GMT

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