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

[Dawit A]

On Fri, Feb 4, 2011 at 12:25 PM, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> On Friday 04 February 2011, Thiago Macieira wrote:
>
>> 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 data
>> > just
>
>> > like it mirrors GET in how it receives it.
>
>>
>
>> A PUT-from-GET operation is called "copy" and we already have that
>
>> operation: KIO::file_copy.
>
>>
>
>> A streaming POST is not a common case, though, because POSTs most often
>
>> require a <form>-like transport or, in the case of SOAP, XML.
>
> Well. The short the form-like posts are not a problem. The point was to fix
> big posts.
>
> I am not sure it is important, but POST is often misunderstood, it is not
> like copy at all. From an abstract point of view it is a translation. You
> send something to a place and get something else in return.
>
> GET: url -> data
>
> PUT: data -> url
>
> Copy: url -> url
>
> POST: data -> url -> data
>
> In KIO get and put has been implemented like:
>
> GET: url -> stream of data
>
> PUT: stream of data-> url
>
> But POST still required data upfront:
>
> POST: data -> url -> stream of data
>
> The case we are trying to solve is not having data be concrete data, but
> instead a source of data.
>
> So somekind of
>
> POST: stream of data -> url -> stream of data
>
> Again. I am not sure such a solution is necesary. I just felt it was a
> suggestion that should be made, because it would make the architecture..
> Well, more pleasing in my mind ;)

I concur with everything you stated above, but I fail to see why these
new APIs would be better if they took KIO job instead of QIODevice.
How would the client use that API ? It would have to create a KIO job
with the post data first, but what kind of job would that be ? It
would then have to use yet another job to post the data ? Is that not
a bit more convoluted ? Perhaps I misunderstood your entire
suggestion.

On the other hand I think I get the KUrl parameter idea if it meant
that the client app will have to create the encoded data to POST/PUT
to the remove server, e.g. a temporary file, and provides that URL to
the job. The key word here being that it must do the necessary
encoding itself even when the request is to simply upload a bunch of
files to a server. Was that the idea ? If so, I do not see why that
could not be done in addition to these two new APIs either.

Regards,
Dawit A.