[Patch] Webdav properties in UDSAtoms

[Best, Jan-Pascal van]

Hamish Rodda wrote:
> 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 :)

That's the spirit!

> > 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 ;)

It sure was!

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

A special() can always return stuff in the metadata, or (like the get
method)
emit data using the SlaveBase::data() method. In whatever way we do
this, the
application only sees the WebdavJob.

I'll try my hand at a beginning of this maybe this weekend.

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

Okay, so it's special() and some wrapper code to make it look nice
to applications.

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

Is that so? I would think the ioslave would pass a QString to the
WebdavJob, 
but the job is in the same process as the application, so can't the job
interpret the XML data?

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

Where SEARCH was implemented in the first try...

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

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

Well, my first SEARCH implementation wasn't so nice itself...

Cheers

Jan-Pascal