RE: Issue: Locking namespaces vs. resources

I'm perfectly happy if we clearly specify that the appropriate
part of the namespace must be share LOCK'ed along with the resource.
I do think that this needs to be cleared up in the spec.

Jim?

> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Saturday, May 26, 2001 11:10 AM
> To: Eric Sedlar
> Cc: WebDAV WG
> Subject: 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 Sunday, 27 May 2001 10:40:36 UTC