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.

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

A DAV client doesn't do a GET in order to start editing a resource.
It MUST, for many reasons, perform a PROPFIND on the resource.  When it
does that on a resource that is not capable of being edited, such as
a dynamic-content resource, it will receive the information necessary
to tell the it and the user that to go edit these other URI (as provided
by dav:source) in order to modify the content.  When the user picks one
of those to edit, the client software will then do a PROPFIND on that
other URI, and will continue this recursively until it gets to a resource
that is static and authorable.

There simply is no other way to implement authoring using the Web interface
without assuming that everything is a static file, and not assuming that
was the whole point of defining a WebDAV protocol in the first place.
If editing files was good enough, we'd just us FTP and rsync.

....Roy

Received on Friday, 1 March 2002 20:27:04 UTC