Making kio_http more accessible to RESTful clients
spillner at kde.org
Fri Oct 10 08:58:38 BST 2008
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
> > - 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
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.
More information about the kde-core-devel