As can be seen with my recent commit [1] that reverted my own previous patch, I recently spent sometime trying to find out how KIO's ioslave-on-hold feature was originally designed to work and more importantly why it reliably fails in certain situations. Here is what I found out:
#1. The ioslave-on-hold feature only works properly if the "transfer" of the ioslave being held is to a newly started application. IOW, if you type a url in KRunner (ALT+F2) and enter a web address which gets opened in Konqueror, then the ioslave that was put on hold will be properly reused by Konqueror. However, if you repeat the same action to open another url and that request is just opened in a new tab on the already running instance of Konqueror, then the ioslave that was put on hold will NOT be reused. Instead Konqueror will create a brand new request to retrieve the page. Why does that happen ? Well, the flag that determines whether or not a look up for held ioslaves should happen is only initialized to true when an instance of KIO::Scheduler is created. And that happens only once for any app that uses KIO since KIO::Scheduler is a singleton class. As a result the aforementioned flag is never reset to true once it was set to false after the original reuse. And no the flag is important and cannot be done away with since KIO::Scheduler is responsible for managing all the network requests for an app. The last thing you want it to do is make these expensive dbus calls to query klauncher for held ioslaves all the time. However, there already exists a solution to the problem. Whomever implemented this feature has already added a static function, checkSlaveOhHold, to KIO::Scheduler to manually reset the flag. The only problem is that that call needs to be made from the each application that receive a request to open the resource. It is the only one in a position to know where the request actually came from. However, I do not know of any app that does this right now. #2 The other reason why put on hold fails is due to specific optimizations done in some ioslaves. The most prominent example of this is kio_ftp. If you click on an FTP link to text file, e.g. , or PDF link or any other link that can be opened by a KDE application from Konqueror or Dolphin, then the process that want to determine the content-type, so the request can be opened with the proper application, will do a get request and once it receives the mime-type, it puts the ioslave on hold. It then creates a request for the appropriate application to open the resource. Unfortunately, application such as kate/kwrite and okular seem to do a file_copy request first before attempting to open the request. Since the ioslave that was put on hold was used to do a GET request while the applications wanted a local copy and requested COPY, the held ioslave will never be used. It will eventually get discarded, but it will potentially cause multiple connections to the same server for the same resource. Actually even with the COPY call the ioslave being held could have been reused if the job was the one doing the copying by connecting a GET sub job with a PUT sub job. However, ioslaves like kio_ftp implement their own copy functionality that allows them to directly copy the remote resource to a local file or a local file to a remote server. That means there will never be a GET subjob outside of the ioslave itself and hence no reuse. Not sure about the solution for this issue... [1] https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f79106a7af685ae330d5db2fb9b678d550875f56
