[Patch] Webdav properties in UDSAtoms

[Best, Jan-Pascal van]

> From: Hamish Rodda [mailto:meddie at yoyo.its.monash.edu.au]
> On Mon, 3 Jun 2002 17:33, Best, Jan-Pascal van wrote:
> > From looking at the patch, there's still some issues IMO:
> > - I think we should leave out the special case handling for
> >   empty "davRequestResponse" metadata. If an application is
> >   smart enough to send this request, it's smart enough to
> >   enter the "<D:prop><allprop/>", right?
> 
> Well, if it does that, how do we know whether or not to 
> append the properties we need? 

In http.cc, we only append the properties if there is
no davRequestResponse set, i.e. if we're in compatibility
mode. Only e.g. Konqueror would not set davRequestResponse,
and expect the default properties to be set.

It looks like this:

  request = "<?xml version=\"1.0\" encoding=\"utf-8\" ?>"
    "<propfind xmlns:D=\"DAV:\">";
  if ( hasMetaData( "davRequestResponse" ) )
    request += metaData( "davRequestResponse" ).utf8(); // this contains
the complete <prop> element
   else {
     request += "<D:prop>";
       "<D:creationdate/>"
       "<D:getcontentlength/>"
       "<D:displayname/>"
       "<D:source/>"
       "<D:getcontentlanguage/>"
       "<D:getcontenttype/>"
       "<D:executable/>"
       "<D:getlastmodified/>"
       "<D:getetag/>"
       "<D:supportedlock/>"
       "<D:lockdiscovery/>"
       "<D:resourcetype/>"
     "</prop>;
    }
    request += </propfind>";


> > - As a workaround for the unfinished <prop> element awkwardness,
> >   can't we require from the application side that the standard
> >   elements (creationdate,getcontentlength,etc.) should always
> >   be queried? That would make the http.cc part so much simpler.
> >   Does anyone know what would go wrong if this application
> >   doesn't comply, but also does not make use of the returned
> >   UDS creation date etc.? I'll also be trying this.
> 
> 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.

> Is the unfinished prop such a 
> problem? if so, we could add another metadata to specify any 
> additional namespaces required.

I think it looks very untidy...

> If the app doesn't comply, we won't even know whether the 
> item is a directory or a file

We won't know, but the application doesn't want to know, 
so that shouldn't cause trouble.

> but I don't think it will crash on us, just return 
> basically no info.

I think there are two kinds of apps:
- ones like konqueror, that just have a URL without being aware
  that it's a webdav url. They just stat it and expect behaviour 
  like a http: URL
- ones like the exchange plugin, that do know they're dealing 
  with webdav. They ask for specific properties of webdav resource
  and only expect those properties to be present. Also special webdav
  browsers fall into this category

> If you still think the best solution is just letting the app 
> take over, I don't really mind.

That's what I think.

> > BTW: Next will probaly be the PROPPATCH method, when I 
> start thinking
> > about write access to Exchange server (shudder). I guess 
> that will have
> > to be special() function? Another idea might be to create a generic
> > WebDavJob class, and the appropriate KIO::webdav() function, with
> > as arguments the URL, the HTTP_METHOD and the XML request. 
> The result
> > would be the XML reply. Would this conflict with the KIO concepts
> > (David?)
> 
> 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!

In general terms, I think we should not try to fit all webdav
methods into the current kioslave actions. I think it is growing
into too much of ad-hockery at the moment. 

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.

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.

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. It would also allow us
to lift some of the webdav-specific parts of http.cc (like davLock)
out of http.cc and into something else. http.cc could use a little
slimming down ;)

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.

Don't forget the patch to global.h for the UDS_XML_PROPERTIES, by 
the way!

Sorry for the long mail.

Cheers

Jan-Pascal