- From: CJ Holmes <cholmes@4d.com>
- Date: Wed, 6 Mar 2002 12:15:22 -0800
- To: DAV <w3c-dist-auth@w3.org>
> > It is common because it is the only way to deploy DAV under the > > current spec. It causes no end of confusion amongst people who are > > deploying/using DAV for the first time. It is counter-intuitive, and >> is not really useful in most situations. > >These are completely subjective arguments. Some people like the one >approach, some like the other. The argument may be subjective to you, but the number of dollars that have to be applied to remedy the situation are not. It's the most common support problem for every organization that we've seen deploy mod_dav, our DAV, or other DAV solutions. DAV + newbie users == high support costs. Any many, many of those phone calls and emails turn out to be users who don't read the little pamphlet/webpage that the IT department prints explaining that they have to use a different URL from their DAV client. Normally we fix support problems by fixing bugs, changing the default configuration, or making the UI more intuitive. What is frustrating about this problem is that it can't be fixed because of the DAV spec. There is no way to use a DAV client to modify source at the same URI as the output, even though that's what most people expect. Using DAV:source isn't an answer because: (1) everyone who advocates it agrees that DAV:source as specified now is insufficient. (2) In a general-purpose web server there is a very real messiness with trying to get the right DAV:source property onto all of the dynamically generated resources. A web server may have dozens of modules that dynamically generate content, all of which might have very different definitions the URI spaces that they handle. (3) I think client support for DAV:source (once the spec is fixed) will be a long time in coming because it will take time to understand the issues. (4) You don't get anything extra with DAV:source beyond what you could have with Translate. (Until DASL and friends make the scene, that is.) cjh --
Received on Wednesday, 6 March 2002 15:20:53 UTC