Review Request: [PATCH] Make the FTP ioslave emit mime-type of the content before actually reading it

[David Faure]

> On April 18, 2011, 12:43 p.m., David Faure wrote:
> > kioslave/ftp/ftp.cpp, line 1766
> > <http://git.reviewboard.kde.org/r/101149/diff/1/?file=14721#file14721line1766>
> >
> >     Maybe this should be "while we haven't read 1024 bytes", but of course the file could be smaller than that so it would have to check for that too.
> >     
> >     What I mean is: I assume peek() doesn't wait, so if the first packet we get is 48 bytes, we have only 48 bytes. Don't know if this is a real problem in practice though, feel free to ignore this comment.
> 
> Dawit Alemayehu wrote:
>     No actually that is a good point. Perhaps a good compromise would be to wait for the 1024 bytes whenever the size of the content to be retrieved is known to be larger than 1024 bytes ? That way for the large enough files, we have a better success of getting a more accurate mime-type and for the others well we do the best we can. :) I will see what I can do about it. For the record, I did test this change with a small enough file, ftp://ftp.kde.org/pub/kde/README_UPLOAD, which happens to be only 404 bytes. Here is the log:
>     
>     kio_ftp(2902) Ftp::copy: ftp "/pub/kde/README_UPLOAD" -> local file "/tmp/kde-dalemayehu/konqueroraj1566"
>     kio_ftp(2902) Ftp::ftpDataMode: want I has ^@
>     kio_ftp(2902) Ftp::ftpSendCmd: send>  TYPE I
>     kio_ftp(2902) Ftp::ftpResponse:     >  200 Switching to Binary mode.
>     kio_ftp(2902) Ftp::ftpResponse: resp>  200 Switching to Binary mode.
>     kio_ftp(2902) Ftp::ftpSendCmd: send>  SIZE /pub/kde/README_UPLOAD
>     kio_ftp(2902) Ftp::ftpResponse:     >  213 404
>     kio_ftp(2902) Ftp::ftpResponse: resp>  213 404
>     kio_ftp(2902) Ftp::ftpDataMode: want I has I
>     kio_ftp(2902) Ftp::ftpSendCmd: send>  PASV
>     kio_ftp(2902) Ftp::ftpResponse:     >  227 Entering Passive Mode (131,220,16,1,22,193).
>     kio_ftp(2902) Ftp::ftpResponse: resp>  227 Entering Passive Mode (131,220,16,1,22,193).
>     kio_ftp(2902) Ftp::ftpOpenPASVDataConnection: Connecting to  "131.220.16.1"  port  5825
>     kio_ftp(2902) Ftp::ftpSendCmd: send>  retr /pub/kde/README_UPLOAD
>     kio_ftp(2902) Ftp::ftpResponse:     >  150 Opening BINARY mode data connection for /pub/kde/README_UPLOAD (404 bytes).
>     kio_ftp(2902) Ftp::ftpResponse: resp>  150 Opening BINARY mode data connection for /pub/kde/README_UPLOAD (404 bytes).
>     kio_ftp(2902) Ftp::ftpOpenCommand: connected with remote.
>     kio_ftp(2902) Ftp::ftpGet: ftpGet: Emitting mimetype  "text/x-readme"
>     kio_ftp(2902) Ftp::ftpGet: ftpGet: starting with offset= 0
>     kio_ftp(2902) Ftp::ftpGet: ftpGet: done
>     
>     I will see what I can do about improving the code as suggested...
>

Yes, but careful with the case where the size is still "unknown" (I suppose it can happen).


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101149/#review2723
-----------------------------------------------------------


On April 18, 2011, 2:12 a.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101149/
> -----------------------------------------------------------
> 
> (Updated April 18, 2011, 2:12 a.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Summary
> -------
> 
> The attached patch changes the ftpGet function such that it emits the mime-type of the content it is about to read, before starting to read it. That way kio_ftp will work correctly if and when it is put on hold to be reused from another application. Note that the patch uses QIODevice::peek to achieve this goal.
> 
> 
> Diffs
> -----
> 
>   kioslave/ftp/ftp.cpp 64f43d8 
> 
> Diff: http://git.reviewboard.kde.org/r/101149/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110418/ba5ab03b/attachment.htm>