----------------------------------------------------------- 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 > >
