Re: Locking: Implementation Considerations

I'd be quite happy to dump Depth:infinity locks from mod_dav. There is a lot
of code in there to deal with those things. Keith Wannamaker did a good job
writing it all and may be sad to see it go :-), but in the best interest of
things... I'm game.
Cheers,
-g
----- Original Message -----
From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
To: <JSlein@crt.xerox.com>
Cc: <w3c-dist-auth@w3.org>
Sent: Wednesday, August 18, 1999 2:33 PM
Subject: Re: Locking: Implementation Considerations
> I believe that in the context of advanced collections (multiple
> bindings to a single resource) and versioning (multiple workspaces
> providing different views of the same URL hierarchy), Depth:infinity
> locking will be undesireable both for clients (does the wrong thing)
> and for servers (too expensive to implement).
>
> >From the server side, Judy has described the difficulty of
> implementing Depth:infinity locking in the context of multiple
> bindings. With the introduction of versioning, with rule-based
> selection of each versioned collection on the URL path to a versioned
> resource, the cost of maintaining Depth:infinity locking increases to
> an even more unacceptable level.
>
> >From the client side, a Depth:infinity write lock on a collection will
> lock all properties of all resources in the workspace's view of that
> collection. This effectively prevents labeling and creating
> successors of those resources by another user in *any* workspace,
> effectively eliminating many critical aspects parallel development.
>
> In contrast, Depth:0 locks work just fine, since normally you would apply
> them only to the working resources you have checked out, and those are
> not visible in other workspaces anyway.
>
> So what conclusion can one draw from all this?
>
> One possibility is to say that locking is largely unneccessary in the
> presence of versioning (after all, everything is read-only unless you
> explicitly check it out into your workspace), so versioning servers
> just won't bother with locking at all. This would have an unfortunate
> interoperability result on Class-2 clients try to work with versioning
> servers.
>
> Another possibility is to downgrade Depth:infinity locking to a MAY,
> thereby warning clients that they are likely to find this not supported,
> and to turn the default lock into Depth:0, instead of Depth:infinity.
> The latter will cause an interoperability issue with existing class-2
> servers, but since there aren't many of those yet, if we move fast, this
> would probably be OK.
>
> Cheers,
> Geoff
>
> From: "Slein, Judith A" <JSlein@crt.xerox.com>
> Date: Thu, 5 Aug 1999 17:13:56 -0400
> Mime-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2448.0)
> charset="iso-8859-1"
> Resent-From: w3c-dist-auth@w3.org
> X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3120
> X-Loop: w3c-dist-auth@w3.org
> Sender: w3c-dist-auth-request@w3.org
> Resent-Sender: w3c-dist-auth-request@w3.org
> Precedence: list
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Length: 1787
>
> One of the issues we've been talking about is what should happen if you
MOVE
> a resource into a locked collection. What lock should be on the
resource
> after the MOVE?
>
> I think the question is whether collection locks with Depth: infinity
should
> be inherited statically or dynamically. Should a collection lock with
> Depth: infinity affect just those resources that are in the collection
at
> the time the lock is created (static inheritance), or should the lock
affect
> whatever resources come into the collection while it is in force (and
stop
> applying to any resources that are removed from the collection)
(dynamic
> inheritance)?
>
> Static inheritance suggests that the lock would be maintained on the
> collection and also maintained on each resource in the collection to
depth
> infinity. It would be painful to create this lock, and painful to
remove
> it, and while it is in force it would be necessary to keep track of the
> MOVEs out of the collection in order to be able to remove the lock
correctly
> in the end. However, if every lock is maintained on each resource it
> affects, it is easy to tell whether a given resource is locked.
>
> Dynamic inheritance suggests that the lock would be maintained only on
the
> collection. It is easy to create and remove such a lock. But it is
> difficult to tell whether any given resource is locked when someone
attempts
> a PUT, MOVE, etc. Especially once the BIND method is available, you
would
> have to trace from the resource in question upward through all the
bindings
> on all the collections in the hierarchy to find out whether the
resource is
> locked.
>
> Currently, section 7.7 of RFC 2518 requires dynamic inheritance of
locks.

Received on Wednesday, 18 August 1999 18:47:25 UTC

AltStyle によって変換されたページ (->オリジナル) /