RE: Locking: Implementation Considerations

I am scared that the server folk are riding rough shod over the needs of the
client folk. This has been the rule, rather than the exception, in the HTTP
world. There are huge numbers of server makers but very few client makers. 

Just take a look at www.webdav.org. There are roughly 17 servers and 5
clients and most of those clients were written by server guys who only
provide APIs rather than real apps. In practice this means that the group
often thinks it has rough consensus because all the server guys have agreed
amongst themselves that they would like to make their lives easier. So
please pay special attention to the painfully few client folk who are
actually hanging around.

As for depth infinity locks, I agree that this is hard for a server to
implement. But it is also critical for a reasonable client to operate. For
example, if I am going to go change my web site I don't know which files, in
particular, I am going to change. So I want to make sure that the whole site
is locked so I don't have to worry about anything becoming inconsistent
while I wander around the site making changes.

It is unrealistic to expect clients to send, even pipelined, series of lock
requests because the chance of getting all those locks at once is low and
having to constantly retry is unrealistic, especially because of the latency
involved.

Therefore clients MUST have depth infinity locks or WebDAV can't meet their
needs.

This having been said, I fully appreciate that depth infinity locks are hard
to implement and may be inappropriate for versioning scenarios. I wouldn't
have a problem with us saying that versioned resources won't support depth
infinity. Frankly I think it would be inappropriate (and here I disagree
w/the versioning group) for a level 2 client to work directly with versioned
resources. I expect a more realistic scenario is that versioned systems will
expose a particular view in a defined namespace and level 2 clients will
then manipulate that view. It is in that view that depth infinity locking
will be implemented.

			Yaron

> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Thursday, August 19, 1999 6:06 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Locking: Implementation Considerations
> 
> 
> 
> 
> I too would be happy to see Depth: infinity locks go. As 
> Geoff says, they should
> be substantially unnecessary with versioning systems. They 
> were hard and
> expensive to implement, and have the effect of reducing 
> resource availability.
> Perhaps users should be more proactive about their locking 
> and use clients to do
> "depth" locks when necessary instead of having this facility 
> implemented
> directly in the server. A client could support a user 
> interface consisting of a
> "Lock Deep" menu item on a selected collection which iterated 
> over the members
> of the collection (recursively or not depending on a user 
> option) and lock the
> members. This would require a lot of round trips, and would result in
> best-effort locking, but this shouldn't be a significant 
> performance or
> usability constraint for the few times this capability should be used.
> 
> 
> 
> 
> 
> "Greg Stein" <gstein@lyra.org> on 08/18/99 06:45:08 PM
> 
> To:   "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>, 
> JSlein@crt.xerox.com
> cc:   w3c-dist-auth@w3.org
> 
> Subject:  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 Thursday, 19 August 1999 13:17:30 UTC