- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 28 Dec 1998 20:13:57 -0800
- To: "'Larry Masinter'" <masinter@parc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
And Larry Said: > The WG decided to do this because the WG decided they felt like > they wanted to like it. But this is circular. Technical decisions > need a technical justification, not a feeling. Examples of use. > Applications that cannot be performed with out. Scenarios. > As I pointed out in my paper, a major issue for vendors was the ability to have multiple access mechanisms to their existing systems. Meaning that they want WebDAV clients hitting against the file system but they also need their currently existing clients, which talk directly to the same file system, to keep working. Maintaining the industry's multi-billion dollar investments in existing software platforms seems like a fine motivation to me. > It's pretty clear that the WG _hasn't_ decided to deal with links. > And the problem is that if you have clients that assume that there > aren't links, you can't actually add links later, without changing > all of the clients. Windows applications that run against SAMBA > servers on Unix boxes have severe interoperability problems when > running against such servers. We gave existing clients a way to ignore linked resources safely by specifying an external URL in the PROPFIND response. > If there are 50 different file system models which are all > incompatible > in the details, then you can only match one if "match" is your goal. > Links, ACLs, file system name restrictions, allowable character sets > in file names are all examples of problems that have come with > trying to do cross-platform file system emulation. If we really > stuck to "web authoring" instead of "file system emulation", we would > have a more solid protocol. > The WG's goal is to provide the features needed to do authoring in a manner that remain compatible with existing stores. No more, no less. Strangely enough the driving force behind links has been this researcher you may know from Xerox, I assume her interest isn't in making WebDAV a file system protocol. As for ACLS, I agree that agreement on this feature may prove to be impossible because of the compatibility issues. Still, I was very heartened to see the progress made at the ACL breakout and actually have hope now that a real solution may be possible. As for naming rules, yes, true bear. The solution we choose, however, should be one you like very much. We made none. Most systems have similar enough naming rules (outside of internationalization which I address below) that explicit rules weren't necessary. If we are wrong, it should be of little consequence to you since you don't seem interested in the goal anyway. So if we are right, you get what you want. If we are wrong, you get what you want. > The fact that client/server pairs that want to do some kind of > file system emulation seem to need a large number of additional > live, operational properties to do so seems like a failure to me, > as long as "emulating a file system" is on your requirements list. > Frankly, I think they'll also have additional operational difficulties > when dealing with character sets in file names, too, unless > they commit to draft-masinter-url-i18n. I'm not sure what you mean by operation properties. WebDAV only includes read-only live properties and their inclusion was not the result of a design necessity but rather mistaken assumptions on the part of the WG. This is one of those "live and learn" situations. "emulating a file system" was the WG's goal. Rather "providing full support for authoring while maintaining compatibility with the millions of deployed stores" is. In the case of file names, we do not make the situation any worse. I for one happen to be a strong supporter of draft-masinter-url-i18n and thanks to the efforts of Chris Wendt IE 5.0 has already implemented support for it. The sad joke is that in many cases we are forced to default support to off because otherwise IE stops working with existing deployed servers which expect their clients to encode URLs using the same code page the server uses. This mess will take a couple of years to work out. But it certainly isn't an issue created by or unique to WebDAV. > > Larry > Yaron
Received on Monday, 28 December 1998 23:14:06 UTC