RE: Issue: Locking namespaces vs. resources

> > 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?


> 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.

That cites a case why people (an administrator) would want to move
resource,
not my point about why people would want to allow a resource that they have
locked to be moved by someone else.  I'm sure there are other cases where
people would want to move resources and they might happen to be locked by
someone else, but my point was that it doesn't seem likely
that anyone would want to allow someone else to move the resource they have
locked because it probably would prevent them from putting their change on
the
server.  For this reason, if they were given a choice, I assume they'd say
they'd
want to lock the resource, so giving them an option doesn't seem like an
effective
approach.  But it might be and I offered two situations where I think they
might be
willing to let their locked resource move, but those *seem* unlikely.


> > I think there is an alternative algorithm that can be used whereby
locking
> > marks the bindings between the locked resource and the root resource
> > ...
> > 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?
> O(log(n)) can still be expensive as n grows, and some people want a very
> large n on their website.
I was somewhat in error.  The "n" I cited for O(log(n)) the number of
collections
in the namespace, not the resources in the name space of that site.  That
obviously likely to be much smaller.  In fact I just did an informal survey
of 1200 websites on the web.  It looks like the average depth of a resource
is about 3 directories deep.  At the max I saw a handful of resources at
6 levels deep.  A couple sites made heavy use of resources 5 collections
deep.

<<
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.
>>
Yup.  I'd expect it to be less also.  Just not much less.

It seems like making locks also protect the namespace is the way to go.
Have I missed something?

J.

Received on Saturday, 26 May 2001 14:23:18 UTC