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

[Dawit Alemayehu]

> On April 18, 2011, 10:38 p.m., David Faure wrote:
> > Looks ok now. Let's hope it works, too :-)

In terms of sending the mime-type it definitely works and is an essential part of the fix to make put-ftp-ioslave-on-hold happen. 

However, putting ftp ioslaves on hold still will not work for most use cases because of a decision made in the ftp ioslave. Namely, the implementation of Ftp::copy to speed up the retrieval a resouce from a remote to local resource. I also found out the croner cases where putting slaves on hold fails and why, but I will save those for another discussion I am going to bring up soon.


- Dawit


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


On April 18, 2011, 10:29 p.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, 10:29 p.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.h 9814c10 
>   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/37d237a8/attachment.htm>