A KIO daemon

[Aleix Pol]

On Thu, Jan 15, 2015 at 7:25 AM, David Faure <faure at kde.org> wrote:
> After the discussion on https://gerrit.vesnicky.cesnet.cz/r/#/c/323/, I just
> had another idea (inspired by a discussion with Alex Fiestas (iirc) long
> ago)...
>
> We could combine the 4 kded modules installed by KIO into a single daemon, say
> "kiod".
>
> These modules are:
> kssld + kcookiejar + kpasswdserver + proxyscout.
> and the favicon module, which should really move in there too, from libkonq,
> since KIO has a runtime dependency on it.
>
> "kiod" would still use KDEDModule as the base class for modules to load, i.e.
> it would be a lightweight kded (without the ksycoca stuff, the dependency on
> kdeinit, or even the legacy KService dependency).
>
> And since all these modules provide services on request (rather than being
> things that have to run all the time, like some kded modules that are doing
> some watching), there's no need to explicitly start kiod during the boot
> sequence, it just gets autostarted via DBus whenever the first call to it is
> being made.
>
> This solves issues like "I need a cookie, this starts kded, which itself has a
> long list of modules to load on startup". kiod would not do that, modules
> would all get loaded on-demand (the first ssl-enabled slave loads kssld, the
> first http slave loads cookiejar, the first slave requesting a password loads
> kpasswdserver, etc.)
>
> It seems to me like a good intermediate solution between "everything depends
> on kded" and "everyone of the 28 kded modules becomes a standalone daemon".
> KIO would have its own daemon, grouping 5 or more of these modules, and that
> keeps things modular, resolving a bit of the kded<->kio inter-dependency (*)
> (at least for KIOCore... I still need a replacement for ksycoca before the
> same can be said about KIOWidgets).
>
> (*) not a real compile-time inter-dependency, but rather the fact that the KIO
> unittests have to work without kded since kded is a runtime dependency of KIO,
> which depends on kio at compile-time (indirectly).
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5

+1
Sounds good to me :)

Aleix