Why KIO's put-ioslave-on-hold feature sometimes does not work...

[Dawit A]

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