- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Mon, 28 Dec 1998 14:20:48 PST
- To: "Yaron Goland" <yarong@microsoft.com>, "WEBDAV WG" <w3c-dist-auth@w3.org>
You keep on giving non-technical answers. "Why is it useful? The WG felt it was useful". Useful for what? > Actually the WG decided to do this because they felt they needed it. 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. > > > A typical HTTP URL looks like > > http://server.com/name1/name2/name3. The > > > HTTP/1.1 specification never defined what the "/" really meant. > > > Did the "/"s have any meaning or were they just decoration to > > > help people remember where they put their resources? This was > > > one of the very first problems the WebDAV Working Group > > (WG) had to face. > > > > It's not clear why this problem was 'faced' by the working group. > > I mean, does the "1" in "name1" have any meaning, or is it just > > decoration? Why is this a problem? > > > As I said in the paper, the WG felt that defining "/" to have a > meaning, as is done in file systems, was a useful thing. Cheese is a useful thing, too. Should WebDAV have cheese? Since cheese is useful, is "not having cheese" a problem? > > > Most of the WG had the very definite idea that WebDAV should > > > provide at least file system level functionality. > > > > The problem is that the notion of 'file system level functionality' > > is pretty fuzzy, and 'at least' is even fuzzier (which file system?). > > Even though most of the WG might agree on a general principle, it > > isn't clear that this is a good decision process for deciding on > > a particular feature. In particular, it might be desirable to have > > a client be able to determine at least one collection that contains > > a given resource, if one is known, but it's not at at clear that > > the requirement that there be a single canonical parent that contains > > any resource corresponds to 'at least file system level > > functionality'. > > In fact, we have lots of counterexamples of file systems for which > > this requirement doesn't match at all (just to pick one example, > > unix file systems which allow 'hard links'). > > > > Actually, I specifically pointed out links as an exception that the WG > decided to deal with separately. Given that UNIX supports the identical > hierarchical structure to WebDAV it was felt that we could also add hard > links later, UNIX did. 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. > > > document management types who didn't really use file systems, they > > > understood that file systems were the single most common form of > > > storage on the planet. Matching file system functionality > > > meant providing at > > > least the possibility of supporting a hierarchical namespace. > > > > But WebDAV doesn't "match" file system functionality in this > > regard. Rather, WebDAV chose to emulate a very restricted > > model of file system, and require this model for all of > > the WebDAV servers. > > > > What do we fail to match? 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. > > > So the WG decided that the "/"s could represent a hierarchical > > > namespace and that it was WebDAV's job to provide the tools to > > > create and maintain that hierarchy if the client/server choose > > > to make it hierarchical. > > > > It's exactly this problem, that the client and server mutually > > have to agree on the semantics, that makes this a serious problem > > for WebDAV interoperability. Clients that are written to assume > > DOS-like file systems will not interoperate with other storage systems > > that don't have such restrictive semantics. > > > > Larry > > > > An example of where WebDAV fails would be useful. 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. Larry
Received on Monday, 28 December 1998 17:21:04 UTC