New kio_http branch ?
Waldo Bastian
bastian at kde.org
Tue Apr 22 13:13:55 BST 2003
On Tuesday 22 April 2003 13:27, you wrote:
> We store and then attempt to transmit the buffer to be uploaded in one fell
> swoop. This is becomes a problem when one is uploading say a 100 MB of
> data.
Yes, that should be done in chunks.
> The reason we keep the buffer is to workaround the problem of
> authentication failure. That is if authentication fails the first time due
> to incorrect input for example, we could still re-transmit the data. And we
> need to do this because we cannot re-request the data from
> KIO::TransferJob.
Ugh, that's nasty indeed. Otoh you don't want to send 100Mb only to discover
that authentication has failed and that you need to send those 100Mb all over
again.
This is a rather fundamental problem though since it will also affect
XXX-to-HTTP copies. (E.g. http put, but probably more likely webdav put)
Is there a way to make sure we have authenticated before doing the PUT / POST?
> No. It is not really the fault of KHTML. It is actually a problem with the
> implementation of KIO::http_post and hence KIO::TransferJob which only
> take a QByteArray as an argument. If both this interfaces took a filename
> or a file descriptor, this whole problem would not exist. Any application
> making use of them can then save the data to be uploaded to a temporary
> file as need and pass that information.
>
> Right now if you attempt to upload a large file, KHTML first loads it into
> memory and transfers that data to konqueror, which then copies it into its
> own buffer just in case you want to re-post (back-button), and it sends the
> data to the KIO sub system where kio_http makes yet another copy for the
> aforementioned reason. The picture is a bit better with webdav since the
> KHTML equation is out of the picture. That is why I wrote KIO::PostJob
> which was derived from KIO::TransferJob and posted it to kfm-devel.
> However, no one bothered to take a look at it :(
Must have missed it. (http://lists.kde.org/?l=kfm-devel&m=104520816914645&w=2
I assume?) Looks good although I would keep this blockSize stuff out of the
API.
Did you test the error handling? I think you need to kill the slave when you
hit these KIO::ERR_INTERNAL; conditions, otherwise the slave is kept around
in an undefined state.
Cheers,
Waldo
--
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
More information about the kfm-devel
mailing list