Konqueror as a webdav client?

[Peter Gostelow]

On 01 January 2004 07:07, Dawit A. wrote:
> On Wednesday 31 December 2003 23:33, Peter Gostelow wrote:
> > > I think you completely misunderstood the whole notion. The webdav spec.
> > > does not tell clients how to handle a particular resource.
> >
> > Please read the nestroy link I submitted. For those who can't access the
> > link, here are the relevant parts:
>
> I have already looked at it.  It simply demonstrates how one can implement
> a groupware functionality into an existing client using the webDAV spec.
> But that does not mean that if a client does not support such a feature it
> is not a webDAV client! Please read RFC 2518, HTTP Extensions for
> Distributed Authoring -- WEBDAV.  You can also look at RFC 3253, Versioning
> Extensions to WebDAV. Konqueror, actually kio_http, does not support the
> later spec. But it has built-in support for the first one.

Reading the rfc 2518 prompted me to start this thread. It describes the 
request and response headers, complete with xml bodies, and that threw me. 
All the user data is contained in the headers. So I wanted to know how 
Konqueror does this and couldn't find any info on the websites.

>
> > >From the above the following points are:
> >
> > 1- WebDAV extends the World Wide Web and changes browser behaviour.
>
> Show me where it says it changes "browser behavior" in the original spec.

The spec itself defines the changes. For one thing, it states the client must 
include the propertyupdate element with the PROPPATCH command. This 
definitely changes browser behaviour.

>
> > 2- Users _must_ enter paramater values for WebDAV headers.
>
> Why ? Normal users should not be bothered with such nonsense. Now if you
> were designing a document management system or a version control system
> that might make sense. Even then the webDAV spec. does not make any such
> demands. As with most other specs. it only suggests what a client might
> want to do in certain scenarios but leaves the implementation of how a
> resouce should be presented up to the creators of the client app, as most
> any spec should.

All the data is contained within the header and xml body. It is not possible 
for Konqueror to implement PROPPATCH without getting data (somehow) from the 
user. For one thing, the spec states the client _must_ provide the 
propertyupdate element. Konqueror cannot do this without knowing whether the 
user wants to set, add, or delete properties. It therefore must get the data 
from the user (however implemented) and then build the PROPPATCH header and 
xml body. Am I missing something?

>
> > 3- A URI only defines a resource, not the header, nor the body
> > paramaters.
>
> I do not understand what you mean here...

The rfc 2518 defines three paramaters to a header request:
1- The URI to identify the resource
2- The header type (PROPPATCH, PROPFIND, etc)
3- The xml body (for properties, etc).

The URI alone is insufficient to send a request. Normally, entering the URI 
does imply a GET, but this isn't always true for WebDAV. For example, what 
happens when the URI points to a collection?

>
> > 4- To use Konqueror as a WebDAV client it must provide the extra
> > functionality required in 1 and 2.
>
> Not true. The link you provided shows how one can extend a browser to
> implement groupware functionality using webDAV. It is not the definitive
> guide on what a webDAV client is or should be. Don't believe me. Look at
> how MS implements their so called "webfolders".  And I am sure many of the
> clients listed in the webdav.org site implement the spec. based on their
> own criteria.

I really don't see how Konqueror can implement PROPPATCH without some kind of 
user input. The spec states the client _must_ supply a propertyupdate 
element.

>
> > Apparently, Konqueror does implement the protocol, but not as a web
> > authoring client.
>
> Perhaps not the way you expected it or would like to have it, but it is a
> webDAV client. It allows you to do most of the things described in RFC
> 2518. You can move, delete rename and edit a file.  For example, open kate
> or kwrite or any other KDE editing app. It does not have to be a text
> editor so long as it uses KIO, you can save the file, image or anything you
> edited to webdav://localhost/dav/<filename>. All of it transparently. The
> only thing currently missing is the ability to LOCK and UNLOCK a file in
> applications themselves (it is supported by kio_http). I am sure that is
> something that will be implemented sometime down the road.

Hmm, I don't want to do this, because it generally means going off-topic, but 
rfc 2291 gives useful terminology:

Client - A program which issues http requests and accepts responses.

Distributed Authoring Tool - A program which can retrieve a source entity via 
HTTP, allow editing of this entity, and then save/publish this entity to a 
server using HTTP.

Entity - The information transferred in a request or response.

Clearly, this means Konqueror is a WebDAV client, as you have asserted. So, I 
asked the wrong question:( I should have asked whether Konqueror is a 
Distributed Authoring Tool (dat). I should also refer to the xml body as an 
Entity.

So Konqueror is a WebDAV client which offers limited dat capabilities. Is that 
a better description?

Regards,
Peter