- From: <ccjason@us.ibm.com>
- Date: Wed, 19 Jan 2000 15:55:45 -0500
- To: Fisher Mark <fisherm@tce.com>
- cc: w3c-dist-auth@w3.org
>> That's the key point here. On a direct-mapped webserver (no alias support in the webserver) that uses a singly-linked filesystem like VMS or Win32API-NTFS as a WebDAV backing store, it may make sense for the DELETE to actually remove the underlying file. >> Yes. The files can be deallocated as long as the other requirements are fulfilled. And yes, it might be the right thing to do for a given server. But WebDAV is currently agnostic on that topic. A server it free to do that as long as they stick to the requirements that the proposal outlines. So what are those requirements that need to be fulfilled? If the server supports multiple bindings, it definitely it must not remove any links/resources that are also accessable via another binding. If they aren't accessable via any other binding, then whether they get removed or not is not something a client can currently detect so the server has a bit more flexibility. The only other constraint then is that the server not delete from bottom up, run into a problem half way and leave the job half done. If you can meet this requirement, you can feel free to deallocate all those files. As for a server that doesn't support multiple bindings, we don't have a strict requirement except the desire for consistant and predictable behavior across all servers. I doubt any of us want to actually have two classes of servers out there that have *very* different behaviors for the same operation. As I think I've tried to point out, even the singly-linked repositories that we've discussed to date can meet these requirements. It is my hope that we all can settle on this one DELETE semantic for all servers. As for us all settling on one semantic. The webdav model is not an exact match of any existing repository that we know of right now. Some lack depth locks. Some don't have URI protection. Some only have cooperative locks. Some don't have multiple bindings. Some don't support loops in their bindings. Some don't have strong bindings to collections. Some have features that can't easily be exposed. We all will have our own difficulties implementing any useful spec over each of our existing systems. Sure we could dumb down that protocol, but we'd be left with an FTP look-alike. Sure we could let the spec fragment, but that would limit the value of our work. We've chosen to come up with something that's both functional and interoperable. That means that everyone will have to bend to deal with impedance mismatches between the webdav model and the model that their repositories use. But if we are all willing to do our share of bending, we as a community will really be delivering something of value to the internet community. Jason.
Received on Wednesday, 19 January 2000 15:57:06 UTC