- From: Eric Sedlar <Eric.Sedlar@oracle.com>
- Date: Sun, 27 May 2001 07:32:49 -0700
- To: "Jason Crawford" <ccjason@us.ibm.com>
- Cc: "WebDAV WG" <w3c-dist-auth@w3.org>
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