Review Request: Fix for a couple of KIO put-slave-on-hold bugs

[David Faure]

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



kio/kio/scheduler.cpp
<http://git.reviewboard.kde.org/r/101244/#comment2513>

    Glad to see my idea worked ;)
    Just a question, does it really matter that the emitter of the signal would set m_checkOnHold to true (if you remove m_ignoreOnHoldListChanged)? After all there is a slave on hold now, and maybe in some cases we end up opening this url in this process after all?
    
    I'm not sure the m_ignoreOnHoldListChanged bool is necessary.


- David


On April 27, 2011, 10:57 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101244/
> -----------------------------------------------------------
> 
> (Updated April 27, 2011, 10:57 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> The attached patch address a couple of bugs in the KIO put-slave-on-hold functionality:
> 
> Problem:
> ======
> #1. If a user clicks a link on a page, e.g. ftp://ftp.kde.org/pub/kde/README_UPLOAD, then KRun will first issue a get (CMD_GET) to determine its content-type and put the ioslave on hold so that the application associated with the returned content-type can handle it. In case of our example that would be kate/kwrite. Unfortunately, the ioslave put on hold will not be reused because almost all applications will use KIO::file_copy (CMD_COPY) to make a local copy before opening it. Even then for ioslaves that do not optimize their copy command, the call to KIO::file_copy will properly reuse the ioslave on hold so long as it do not have an optimized copying method like the ftp ioslave. 
> 
> #2. If a user types a web address, e.g. www.kde.org, into KRunner to open it in Konqueror and repeats the same process with another address, then whether the ioslave put on hold the second time around will get reused or not depends how the application works. If the application allows multiple documents or tabs and opens the second url as in the already running instance, then the ioslave on hold will NOT be reused the second time around.
> 
> Solution:
> ======
> #1. Simply force the KIO::file_copy call not to do the optimized copying if there is a slave on hold for the request. This will force it to use two separate jobs, KIO::get (CMD_GET) and KIO::put (CMD_PUT) ensuring the reuse of the ioslave that was put on hold.
> 
> #2. Whenever a call to KIO::Scheduler::publishSlaveOnHold is made, send a dbus message to update all the other scheduler so that they can look for an ioslave-on-hold to service the next request.
> 
> 
> Diffs
> -----
> 
>   kio/kio/scheduler.h 9be9db0 
>   kio/kio/scheduler.cpp 4cb33d1 
>   kio/kio/job.cpp e34f562 
> 
> Diff: http://git.reviewboard.kde.org/r/101244/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit
> 
>

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