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

>  > Yeah, but it's OUR problem, and not yours.  If our DAV implementation
>>  is unsatisfactory to our customers then we have to change it.  But
>>  this would let us (and other implementors) give our customers what
>>  they want, which is DAV access to their source files with virtually
>>  no configuration necessary.
>
>No configuration is necessary with dav:source other than what was already
>done to create the dynamic resource.

I've tried to explain the real-world "hassle for no gain for most 
people" situation on this about five times now.  I'm not going to 
repeat it because apparently nobody on this list thinks such issues 
merit much weight.  But I guess what administrators have to do to 
configure their servers or how much we confuse hapless users is 
inconsequential in the face of the prospect of adding a mote of dust 
to the pure model of DAV.

>  > All we need from the protocol group is a sure way to know that a GET
>>  command originated from a DAV client.  Is that so much to ask?
>
>No, the problem is that your question starts off with an awful design
>decision and expects the WG to validate that through another unnecessary
>and completely lame hack.

It starts with trying to find a way to accommodate users who don't 
give a darn about using DAV on display resources, and would like to 
use DAV to edit their sources without screwing with the URL.  If it 
was just a minority of users, it wouldn't be an issue.  But it is a 
majority of users and installations, so it is an issue.

Translate exists because it solves this problem by identifying GETs 
from DAV clients.  If we have to use Translate to give our customers 
what they want, then so be it.  I was just hoping we could get 
something defined by a group of thoughtful people instead of 
something undocumented.


cjh

--

Received on Friday, 1 March 2002 21:35:53 UTC