On Fri, Feb 4, 2011 at 12:25 PM, Allan Sandfeld Jensen <[email protected]> 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.
