- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Sat, 26 May 2001 14:09:58 -0400
- To: "Eric Sedlar" <Eric.Sedlar@oracle.com>
- Cc: "WebDAV WG" <w3c-dist-auth@w3.org>
> > 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