RE: Collections, Resourcetype and Hierarchy in WebDAV

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