- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Thu, 2 Aug 2001 10:13:41 +1000
- To: w3c-dist-auth@w3.org
I am discussing only for the sake of discussing - not because I actually have a strong opinion on this. On Wed, Aug 01, 2001 at 10:30:22AM +0100, Hall, Shaun wrote: > I think you are taking WebDAV out of its intended context (see below). I would be interested to know what the intended context for other WebDAV implementors are. > You don't need race conditions because your WebDAV layer in the above > example can be circumvented full stop. For example, there's nothing to stop > another non-WebDAV application creating a directory with the same name as > the LNR even though your WebDAV server has created a LNR. If the LOCK requests are passed down to the underlying system and supported by the underlying system, then it *is* possible to stop another non-WebDAV application doing things. My understanding is this is exactly (one of) the reasons why it was being proposed that LNR be changed. For example, I thought it would be a real issue with Oracle iFS. I might have misunderstood. I agree that not all possible implementations of the underlying system will be able to support WebDAV. But if (for example) a LNR request did create a file and lock it in the underlying file system, then other applications *would* be stopped from creating a directory with that name concurrently. This is the whole point. > Unless the heart of your "back end" (in this case a OS's file system) > supports WebDAV, its going to be a "best effort" approach. I agree with this. The question is it worth changing WebDAV to use a model closer to what the majority of file systems do support, to allow more implementations do locking properly (that is, at the file system level, not the WebDAV level). In other words, is it worth minimizing the impedience between protocols/systems? > > (2) Locking is only to protect against other WebDAV clients and not > > against anything else > Actually 2) is correct as well: I agree - this is a valid position to take (which is why I included it). I *personally* dislike it, but it is a completely valid position to take. > Remember that WebDAV is a set of extensions to HTTP, which suffers similar > problems. WebDAV is about WWW functionality, not a "be all and end all" > access mechanism for everything - see section 1 of RFC 2518, read RFC 2291. > This is what I mean when I say you've taken WebDAV out of intended context. I think this weakens WebDAV when there is no real reason to weaken it. > Your example of other applications accessing your Web/WebDAV Server's data > area is not WWW functionality and therefore WebDAV does not apply IMHO. > People have to live with it. Philosophically I think we disagree here. I am interested in WebDAV as a means to maximize integration of systems. To maximize integration it is common to have to support multiple protocols accessing the same information. I think Oracle iFS is a good example of this need in real life. I think Microsoft users using Web Folders want WebDAV to act as much like other file systems as possible and integrate with them as safely as possible. > Is WebDAV going to stop admins/root formatting > the hard disk which contains the data ? Yes. If a lock is held in the underlying file system, it cannot be unmounted (for UNIX anyway), and so cannot be reformatted. You would have to shut down the machine to circumvent this. > In your file system example, there is nothing to stop another application > deleting a file (that is not a LNR) that your WebDAV Server has locked. There is *if* the LOCK is mapped down to something the underlying file system can understand. > Therefore the locking mechanism has failed. If this is truely the case, I would almost consider arguing that locking serves > What mechanism can you invent > that would solve all these multiple protocol problems? If (and it is *if*) all the protocols can map locking requests down to the base level, then there is no problem. In terms of WebDAV my question is "should WebDAV be changed to be a better protocol citizen to make it easier to share an underlying file system with other protocols". No, there is no guarantee. But using more standard semantics would make it much more likely. > In the real world, the end users system in question should be configured so > only HTTP/WebDAV clients can access the data area that the WebDAV Server > interacts with. I would be interested in other implementors feeling on this one. Its certainly not true for our system. Its certainly not true for Oracle iFS. I am pretty sure its not true for Apache mod_dav (its not unreasonable for web site administrators to go to the file system directly). I suspect the same holds for IIS. I have probably said enough on this topic. I am interested in the outcome because it makes a difference to our locking implementation. I am not really stressed which way it goes. I agree that changing the LNR semantics will not solve *all* problems. But I dont think this alone is a reason not to try to reduce implementation/compatibility problems when used in systems with other protocols/systems etc. Alan
Received on Wednesday, 1 August 2001 20:14:35 UTC