Subject: Re: Issue: Locking namespaces vs. resources

From: "Jason Crawford" <[email-masked]>
Date: Fri, 25 May 2001 00:25:45 -0400

<<
There was a long discussion of locking a URL (so that a resource can't
move when locked) in the fall of 1999, and in looking back through the
archive, I didn't get a feeling of resolution that the spec should be
changed in any way.
We didn't resolve it, but we were close.  In Dec 99 the locking discussion
got defered as some of the advanced collections issues were suddenly hotly
debated.

<<
from Yaron, and there were a number of proposals to actually specify
whether you wanted a namespace lock or a resource lock, rather than
leaving this vague.  I still think this is very useful, for performance
reasons
I assume people tend to lock resources because they want to work on them
and modify them.  I can't imagine one wanting to allow folks the resource
they are working on unless... (1) moving it doesn't prevent them from being
able to "check their modifications in".   Or (2) they know there is no one
that will move it.  How common are these?  Are there other cases?

<<
 (I think Greg Stein mentioned that mod_dav must recursively
search the source directory for locks before doing a MOVE for just this
reason--not a good thing)
I think there is an alternative algorithm that can be used whereby locking
marks the bindings between the locked resource and the root resource
of the namespace.  The cost of marking/unmarking should be O(log(n)) where
n is
the number of resources in the system.   The cost of checking before
breaking
a binding should be O(1).  In other words, not expensive if this algorithm
can be used.   Is there a problem doing this?  It doesn't sound expensive.
Is
it?

J.

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 25 May 2001 09:57:28 -0700

> -----Original Message-----
> From: Jason Crawford [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 9:26 PM
> To: Eric Sedlar
> Cc: WebDAV WG
> Subject: Re: Issue: Locking namespaces vs. resources
> <<

That's why I brought it up.  I thought we could resolve this without too
much more debate.

> that will move it.  How common are these?  Are there other cases?

Geoff cited a number of cases where an administrative type of person might
want to move whole directory trees while a user is editing a file.  On UNIX,
this wouldn't be a problem, since the client would have an open file
descriptor, and the data would still get saved.  In WebDAV, the client would
have to process the 302 and use the new URL.

> can be used.   Is there a problem doing this?  It doesn't sound expensive.

O(log(n)) can still be expensive as n grows, and some people want a very
large n on their website.  It's not like it's horrible, though, either.
Keeping track of open locks that must be moved is much easier, however,
since my guess is that the number of open locks will be less than log(n)
on most systems.  So, allowing LOCKED files to move is still less of a
performance burden.

I don't care that much if we want to say that WebDAV locks must always
lock the part of the namespace needed by that URL, or if we provide
clients a choice (it's clear that we must provide a way to lock the
namespace, though).  I think we should just be clear in the spec as to
what locks do, though.

--Eric