---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100516/
---
Review request for kdelibs.
Changes
---
Did some basic testing of
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100516/#review1305
---
Ship it!
Looks good, but...
kio/kio/job.cpp
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100516/
---
(Updated Feb. 7, 2011, 6:46 p.m.)
Review request for kdelibs.
Changes
Is QIODevice the best idea to use as source?
Since we are talking KIO, I believe we can espect the user of KIO::http_post
to be using KIO and not Qt IO. So would it instead be possible to make the
source a KIO job or KUrl?
Regards
`Allan
On Wednesday 02 February 2011, Dawit Alemayehu wrote:
Ahh... I think you misunderstood the purpose of the patch or rather
the title of this review. The new APIs simply overload the existing
http post APIs such that the data you are going to post is sent
through a QIODevice (QFile or QBuffer) rather than a QByteArray. To be
clear here is the new
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
Em sexta-feira, 4 de fevereiro de 2011, às 16:52:54, Allan Sandfeld Jensen
escreveu:
Or to put another way; PUT takes a KUrl to send to and gets the data it
sends from a slot. POST is essentially just a PUT with return data, so I
would find it most natural if POST mirrored PUT in how it sends
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100516/
---
Review request for kdelibs.
Summary
---
The attached patch is the
