[Patch] Webdav properties in UDSAtoms

[Hamish Rodda]

On Mon, 3 Jun 2002 22:15, Best, Jan-Pascal van wrote:
> > I don't really trust the app here. I would guess that most
> > people wanting to use this will have other things on their
> > mind than satisfying the ioslave.
> > Plus, we might need to change them later on.
>
> The last is a real concern. The question is, are applications
> that provide a davRequestResponse that asks for certain
> properties going to look for other properties in the UDS
> structures they get back? I would suppose not.

Ah, I see... works for me, it's all the app's fault when things go wrong :)

> > I'm actually thinking about a hack involving passing the
> > PROPPATCH XML in a
> > get() request, and having the content returned set to the XML
> > which the
> > server returns.  It's programatically simple, and apart from
> > being a bit
> > unorthordox, it doesn't break any of my fundamental moral
> > principles ;)
>
> It does break one of mine: a get() request should only READ
> a resource, not MODIFY its properties!

Erg, yes; but you've got to agree it was a simple patch ;)

> We should either define new actions in kdelibs/kio/kio/slavebase.h
> that are implemented only for webdav kioslaves, or implement a number
> of special()s that are available for application programmers with
> a set of convenience method, or a special WebdavJob class.

Didn't David say a special() couldn't return data? I'm not sure if that's 
right, we could always make our own job class to capture any of the existing 
inputs we want...?

Also, I have been lead to believe that slavebase.h can't change for binary 
compatability reasons; though I could be wrong.

> In my case, I would like to do something like
>   KIO::WebdavJob *job = KIO::Webdav::search( url, query, namespace );
> and in the result() slot read the QDomNodeList with the search results.

Because kio_http will always be a separate process, we will always be passing 
QByteArrays and QStrings, at least until KIO is reworked.

> Let's face it, webdav-specific operations are never going to be used
> in a protocol-transparant way. That's okay for the MOVE, COPY and GET
> methods, but it just isn't for SEARCH, SUBSCRIBE, LOCK, UNLOCK,
> PROPFIND or POLL. We should acknowledge that and offer something
> protocol-specific to use these operations.

Sure. I guess it's time to look into special().

> BTW, the patch seems to work OK, but I only use the SEARCH
> method at the moment, with davRequestResponse. I don't use STAT
> at all, because I can immediately ask for the properties I
> need in the SEARCH query. Konqueror shows the DAV resources nicely,
> though, so I guess that STAT works, too. In spite of my ramblings
> above, please apply the patch for now so that the korganizer-size
> of my work can go on. We might even get the exhange import plugin
> to korganizer ready for KDE 3.1.

Ok, I'm looking into it now. By the way, I'm happy for you to start committing 
things, if you get a CVS account (and remember not to break the "http" in 
"kio_http", some people might get upset :). It's getting close to my crunch 
time with exams...

I'm happy with the solutions so far, thanks for talking me out of broken 
implementations...

Cheers,

Hamish.