RE: Collections, Resourcetype and Hierarchy in WebDAV

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