Making kio_http more accessible to RESTful clients

[Josef Spillner]

Am Montag, 6. Oktober 2008 23:46:37 schrieb David Faure:
> The point of metadata in slaves is to use it, or to send it back to the
> application; at the time of error(), there is no "use it" to be done
> anymore (the current operation is over), and there hasn't been a need to
> sent it to the app until now, since the job is over, but I guess this could
> be changed.

I think most of the metadata can indeed be discarded, but what about e.g. the 
error codes of the underlying protocol which can give further explanation for 
the reason of a job termination? This could be useful information to 
applications which otherwise would have to use QHttp or their own handlers 
just for this missing piece in the puzzle.

> > - deletejob: It surely is an error that it creates a subjob and then
> > dismisses the subjob's metadata?
>
> Arguably, yes. In copyjob we do   m_incomingMetaData += kiojob->metaData();
> when kiojob emits result, I wouldn't be opposed to deletejob doing the
> same.

Ok.

> > - kio_http: Its desktop file only indicates reading capabilities, whereas
> > writing and deleting is also supported. What's the reason behind this
> > restriction?
>
> You mean .protocol file? There's a webdav.protocol which defines this.
> http.protocol doesn't since you can't write or delete over a http url
> afaik.

WebDAV is an extension to HTTP, but HTTP already allows deletion on its own. 
From what I know the first web browsers even had a GUI for that. Right-click 
on image and delete, scary thought :-)
From what I can see there should be no side effects when adding 
writing/deletion to the .protocol file, but then again I don't know much about 
the implications and areas of use of this information.

> > - kio: What is the rationale for having specialised methods like
> > KIO::http_post when all the functionality they include could be expressed
> > by the existing methods? Such methods should be removed or put into
> > convenience classes.
>
> Well it's a convenience method, how is that different from a convenience
> class? "Expressed by existing methods" -- well, not really, if you take
> into account the big security check in that method (precheckHttpPost).

If it's such an important security check, a bit of text for the API docs 
wouldn't be bad :)
From what I can see the check includes things which should be handled at a 
different level, as they're not intrinsic to the protocol (or any protocol), 
e.g. the KAuthorized check. Something like setPreprocessingHandler() comes to 
my mind. Note that my intention is not to rewrite KIO by myself, it is to 
gather requirements and design decisions which could be improved at some point 
when the information about what actually needs to be done is available 
somewhere. Kind of like a high-level TODO file.

Josef