RE: DAV-Enabled field (was RE: A case for GETSRC)

>  > 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