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

[Thiago Macieira]

Em sexta-feira, 4 de fevereiro de 2011, às 16:53:14, David Faure escreveu:
> QIODevice is a "pull" solution - you can ask for "1MB of data now".
> Well, at least with buffers and files, not necessarily with sockets :-)

QIODevice can work in that way too, since Qt 4.4.

If you try to read and come up empty, you can just wait for there to be more 
data via QIODevice::readyRead().

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

The problem of removing the QByteArray overload is that you don't know whether 
the QIODevice you've got has a fixed size or not. Upload operations often 
require an up-front byte count, so a missing size will require a full 
buffering.

Another problem with QIODevice is re-posting. This can happen several times if 
your proxy requires authentication and your target requires authentication. 
QNetworkAccessManager will buffer by default, unless you tell it otherwise.

This new API may need that flag too.

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

You can tell the job to stop transmitting. That's how the datapump works in 
KIO. From job.cpp:

 * The FileCopyJob works according to the famous Bavarian
 * 'Alternating Bitburger Protocol': we either drink a beer or we
 * we order a beer, but never both at the same time.
 * Translated to io-slaves: We alternate between receiving a block of data
 * and sending it away.

See also commit 368947cb6f8bbe384593d1a5cb688373d5949045, where coolo fixed it 
("how could it ever have worked?")

Unfortunately, the actual origin of the commit was lost in CVS history (see 
46864b05, cvs2svn manufactured commit).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110204/90016dac/attachment.sig>