KIO workers and the Qt5->Qt6 transition

[Fabian Vogt]

Hi,

Am Dienstag, 12. Dezember 2023, 15:57:49 CET schrieb Nicolas Fella:
> Hi,
> 
> this is a variant of the plugin problem outlined in
> https://mail.kde.org/pipermail/kde-devel/2023-December/002234.html
> 
> TL;DR Qt6 can't load Qt5-based plugins and vice versa
> 
> This also affects KIO workers.
> 
> We have a number of sources of KIO worker plugins:
> 
> - KIO itself provides file, http, help, ftp, remote, and trash. Since
> KIO is available from KF5 and KF6 we get builds of those for both Qt
> versions. No problem here.
> 
> - kio-extras provides additional workers: sftp, mtp, smb, ... kio-extras
> is available for KF5 and KF6, so no problem here.
> 
> - various kio-* modules, like kio-gdrive, kio-stash, kio-gopher. These
> should be built for both Qts, which should generally be possible, modulo
> some common files to be deconflicted
> 
> - "Applications" that ship a KIO worker as part of their offering.
> Examples that come to my mind are KDE Connect that ships a kdeconnect
> worker and bluedevil that ships the bluetooth and obexftp workers. These
> project are generally not designed to be coinstallable. i.e. if I have
> Qt6-based KDE Connect I can't use the kdeconnect worker from a KF5 app

There's another problem but also another solution: kio-fuse. With yesterday's
5.1.0 release it can be built against KF6 as well, but it's unversioned and has
stable API, so KF5 kio-fuse can be used with KF6 applications and vice versa.

It can be problem because kio-fuse is like an application in this regard, it's
tied to a specific major version of KIO workers. If a protocol is not
available, KIO falls back to plain kioexec.

It can be a solution because through FUSE, KF5 applications can use KF6 workers
and vice versa. There's no plumbing set up for this though and as there can
currently only be one kio-fuse, only one direction is available. If there are
KF5 only workers and KF6 only workers, that can't be fully bridged currently.

> The last case is the one giving me headaches. Possible options would be
> 
> - Ignore the problem and hope nobody misses some workers in some
> applications
> 
> - Make sure all (relevant) workers are available for both Qts, adding
> some complexity to the build, release, and packaging process

Currently it's effectively a mixture of those two options. Make most workers
available for both and hope that nobody misses the rest.

> - Since KIO workers run out of process it should be technically feasible
> to come up with a way to run KF5-based worker plugins from a KF6-based
> app and vice versa. I have not tried to implement that though, and it
> would require some non-trivial surgery on KIO internals

It shouldn't actually be that hard to achieve, but it's probably not a good
option for other reasons:

1. The QDataStream based protocol needs to be kept compatible. Even subtle
   differences in behaviour can cause major issues.
2. To get KF5 based applications to use KF6 workers, which is arguably the more
   impactful direction, it has to be implemented in KF5's KIO as well. That
   means also backwards-compat of the KF6 KIO worker protocol with KF5 KIO,
   which restricts KF6.

Cheers,
Fabian