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

[Allan Sandfeld Jensen]

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 ;)

`Allan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110204/89fe56cb/attachment.htm>