Review Request: New KIO::http_post and KIO::StoredHttpPost APIs that accept a QIODevice as input...

[David Faure]

On Friday 04 February 2011, Allan Sandfeld Jensen wrote:
> Is QIODevice the best idea to use as source?
>I believe we can espect the user of KIO::http_post 
> to be using KIO and not Qt IO

I like QIODevice actually, for reading stuff on demand.
I use it everywhere in KArchive (KZip, KTar...) and KFilterDev.
QIODevice is a "pull" solution - you can ask for "1MB of data now".
Well, at least with buffers and files, not necessarily with sockets :-)
The good thing with QIODevice is that it works on top of both memory (QBuffer) 
and files (QFile), so in kde5 we could even remove the QByteArray overload.
And if you want to send bzip2 compressed data you could even insert a 
KFilterDev to do it "on the fly".

KIO::Job on the other hand is a push solution - it will tell you when it has 
something. Well in this case both would work I guess, slotDataReqFromDevice 
could just send whatever is available, using an intermediate storage for what 
the underlying get job is emitting.
But the only benefit would be "being able to upload remote data", not sure if 
we have a use case for that.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).