[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Preliminary webdav support in kio_http
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-01 1:21:20
[Download RAW message or body]

On Tuesday 1 January 2002, Waldo Bastian wrote:
>On Monday 31 December 2001 01:46 am, Hamish Rodda wrote:
>> I've posted a more up-to-date version on
>> http://yoyo.cc.monash.edu.au/~meddie/patches/
>
>Ah cool, looks good.
>
>Some remarks:
>* Does it need to have it's own "webdav" protocol? Can't it just be used for
>http in general?

There are a couple of reasons for this. The most important one is that it 
needs to know when to send a request for a directory listing (PROPFIND /dir/) 
as compared to a request for the default document of a directory (GET /dir/). 
In fact, having the listing capabilities causes kio to behave very 
differently (calling listdir instead of stat, etc). Plus, I don't know if we 
want the http protocol to think it is capable of copy / move / makedir etc.

>* You define the dtd as a static QString, better define it simply as const
>char * and create a QString from it in the constructor. (Or when first used)

Ok. I currently haven't figured out how to make use of the dtd, if at all, so 
it may just get removed anyway.

>* There is code like:
>          data( m_bufReceive );
>          if ( dataInternal )
>            m_intData += m_bufReceive;
>
>I don't think that such internal data should be sent back to the application
>should it? E.g. I would rather expect something like:
>if (dataInternal)
>   m_intData += m_bufReceive;
>else
>  data(m_bufReceive);

That's what I had originally; it got pretty complex and I wanted to keep the 
patch simple. The only reason to send the data back to the application as 
well is to allow it to receive the properties from the returned xml as well, 
and there's got to be a better way to do that. I'll put it back that way; 
should I do the same for the totalSize(), processedSize() etc calls?

I'm pretty stuck on what to do re. locking files; how can I present some 
interface to allow this in konqueror? Plus, remembering lock tokens would 
need to be done by one of: the interface program (konqueror, quanta+), an 
independant program (could kdesud be extended to store per-url properties?), 
saved to a file (kio_webdavrc?), or added to the url (eg. 
webdav://server/file?locktoken=2t3h5x32nt5h32).

Another question on konqueror generally - where are the KFilePlugins stored?

Cheers,
Hamish
[prev in list] [next in list] [prev in thread] [next in thread]