- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Fri, 14 Jan 2000 09:09:33 -0500
- To: w3c-dist-auth@w3.org
I'll flesh out Jason's example with the resulting lock state (as defined by GULP). From: ccjason@us.ibm.com Ah... Eric's note brings up another possibility. It might be a red herring, but as Geoff's proposal is currently written (and Eric's too I think) it still is a possibly unexpected behavior. User B locks /a/b/ exclusively. Suppose / does not identify a WebDAV resource, but /a does. Suppose that /a/b/c identifies a resource, but /a/b/c/d.html does not. Then the user B lock results in a ["b/.", "tok153"] lock on /a and a [".", "tok153"] lock on /a/b. All locks with token "tok153" have exclusive scope. Although according to 2518, a lock is by default depth:infinity (which I believe is broken, and should be replaced by a default depth of zero), I believe Jason intended a depth:0 lock, so we'll postulate that all locks with token "tok153" are depth:0. User D tries to do a shared lock on /a/b/c/d.html but fails because in the proposal that will also create a lock (or will it?) on /a/b/ which already has an exclusive lock on it. If user D's request succeeded, it would add a ["b/c/d.html/.", "tok192"] lock to /a and a ["c/d.html/.", "tok192"] lock on /a/b and a ["d.html/.", "tok192"] lock on /a/b/c. Since none of these locks conflict with any of the existing locks, user D's request succeeds. In particular, the ["b/c/d.html/.", "tok192"] lock on /a has a different target from the ["b/.", "tok153"] lock on /a, so there is no conflict there. I'm not saying this is good or bad. I'm just pointing it out as what sounds like a difference in the recent proposals relative to what we were proposing a month or more ago. I don't think it is acceptable for the exclusive lock on /a/b to conflict with an exclusive lock on /a/b/c/d.html (so it's a good thing GULP allows it :-). Cheers, Geoff
Received on Friday, 14 January 2000 09:09:39 UTC