Making kio_http more accessible to RESTful clients

[David Faure]

On Sunday 05 October 2008, Josef Spillner wrote:
> Hello,
> 
> to make the creation of clients to RESTful services possible, applications 
> need access to HTTP response codes.
> Since I'm not too familiar with the KIO code, I'm asking here first before 
> putting in my patches from playground/libs/webtech.
> 
> - slavebase: Why is metadata discarded in the case of error()? It seems more 
> useful to me to keep it.

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.

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

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

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

> For KDE 5, my wishlist includes splitting the WebDAV code from the HTTP code, 
> to make the class more maintainable and more useful for other HTTP-based 
> protocols. Also, the API naming convention regarding metadata is very lousy, 
> it is hard to differentiate between outgoing and incoming data, especially in 
> KIO::Job::{setM,m}etaData().

Yep, feel free to clarify the docs. The implementation is rather clear at that place,
e.g. KIO::Job::setMetaData is outgoing, it's metadata that will be sent to the slave,
while KIO::Job::metaData/queryMetaData is the incoming metadata from job.
A bit unusual that the getter and setter are not symmetric indeed, although it
matches the way metadata is used in 99% of the cases  (there's "outgoingMetaData"
for the case of querying the metadata that we have set previously, but that's rare...).
I'm not sure that setOutgoingMetaData() would be considered clearer than setMetaData()
in the common use case...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).