dependency issue (KService* -> KPluginLoader -> KLocale)

[David Faure]

KService, KServiceTypeTrader and KMimeTypeTrader (all of which I moved to a 
new "kservice" framework), all have a template method (createInstance*) which 
uses KPluginLoader to load the plugin described by the given service, or 
trader query.

Which gives two, well, three solutions:

1) Moving KPluginLoader to the kservice framework as well.

2) Moving these template methods out, e.g. into KPluginLoader itself, making
kpluginloader one tier above kservice. the app code change looks like this:
-  Client *client = service->createInstance<Client>(this, ...)
+ Client *client = KPluginLoader::createInstance<Client>(service, this, ...)

3) Making kservice *and* kpluginloader tier1 libs, and having the template 
methods to integrate the two somewhere else, above.


Pro for 1: kservice is apps and plugins, so loading plugins is part of the 
same framework. When Qt-5.1 gets a proper trader equivalent, and once I write 
the libxdg-cache-based application lookup, we can migrate the apps and plugins 
to that, and slowly phase out kservice.

Con for 1: KPluginLoader itself depends on KLocale, since it automatically 
inserts the translation catalog for the plugin. I think that's a good feature, 
it's part of what makes klocale superior to qtranslator, so the only solution 
would be that kservice is tier2, and depends on the klocale framework.
The downside is that the users of KService as an application descriptor 
(kopenwithdialog, krun, kded vfolder, open-or-save dialog...) are getting an 
unwanted dependency.

Pro for 2: solves the dependency issue, although then we still need to find a 
home for KPluginLoader, and that home will be a tier2 [solved by solution 3].

Con for 2 and 3: SIC change, and a weird one:
although the KService template can easily move to KPluginLoader (which already 
knows about KService, so this would just be an extra convenience method), 
KMimeTypeTrader::createInstanceFromQuery really belongs in KMimeTypeTrader 
IMHO. Well, we could have KPluginLoader::createInstanceFromMimeTypeQuery
and createInstanceFromServiceTypeQuery, but this is getting long, not very 
OOP, and it seems like a bit of a reverse depedency hack to put that into the 
plugin loader itself (you do the trader query first, and then the plugin 
loading). To the app developer's point of view, direct plugin loading ("load 
foo.so") is *more* low-level than the trader which can also load plugins... or 
maybe this is just dinosaur-thinking, one could say "the trader is an 
implementation detail of the high-level KPluginLoader all-in-one method" :-)

Con for 3: no idea where that would be, and it's starting to look like weird 
API for the benefit of cutting dependencies. Possibly for no good purpose in 
this case.

Hmm.... another idea:
Solution 1b: move KPluginLoader to kservice, but solve the i18n dependency by 
having some singleton inside KPluginLoader emit a signal when loading a 
plugin, and some singleton in KLocale picks that up and loads the catalog. Too 
hacky? (ugly singletons, and exposing some internal object publically for the 
benefit of one other framework)... It would work, though, I guess...


I had started in the direction of solution 2, because it was ok for the 
kservice template method, but moving the trader ones seems really strange to 
me, so I stopped to write this thinking-out-loud email :-)

I think I'll reverse that and go for solution 1 then, i.e. moving 
kpluginloader and making kservice tier2. (Or possibly solution 1b?)

If this is indeed "temporary" because the proper kf5/qt5 solution is the qt 
plugin metadata querying stuff anyway, then it doesn't matter this much, I 
guess (the kservice framework will be kept for compatibility in any case, we 
have a huge amount of apps and plugins depending on it).

Well, I guess I answered my own (implicit) question here, but if someone has a 
better idea I'm listening :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5