How to deal with dependencies between plugins?

[David Edmundson]

On Sun, Jun 24, 2012 at 4:12 PM, Lasath Fernando <kde at lasath.org> wrote:
> Hey
>
> Okay, this email may *feel* like a wall of text, but if you bear with
> me for a moment, you'll see that it's actually filled with legitimate
> questions.
>
> I started discussing this problem with a friend of mine (CC'ed)
> because he was bored at the time, and these are the issues we came up
> with. I want to start implementing a solution next Wednesday, so I
> would appreciate it if you guys can give your suggestions/solutions
> sooner rather than later.
>
> I outlined a part of the problem of dependencies between plugins in a
> comment on reviewboard.
> But to those who didn't read it, but would like to contribute wisdom
> anyway, the brief rundown is :
> We need to account for a few things. We need a way of identifying the
> dependancies of a plugin, and we need a way of handling the situation
> where they aren't found. We also need to account for the user
> enabling/disabling them. We also need to be able to control the order
> in which they are run.
>
> First of all, filters parse messages, and modify/add parts to the
> message. But they also store metatdata for other plugins to use in the
> form of properties. For example, the UrlFilter adds <a> tags to make
> links clickable, but it also dumps all the urls found as a property so
> that all other plugins don't have to parse it. ImageFilter (which
> embeds links to images directly in the chat) uses that.
>
> So, when I say B depends on A, I mean a situation like that.
>
>
> First scenario. Plugin B requires plugin A, but A is not present.
> (I.e. KPluginLoader failed to load it).
> Should it silently fail, or give a message to the user informing that
> B has failed becuase A is missing?
> Should it then disable it forever, or keep trying in case A comes back
> in future messages?
>
>
> Second case: B requires A but A is disabled.
> Should this be dealt with at runtime, or while the user is
> enabling/disabling plugins?
>
> Doing it at configure time will mean that all relationships between
> plugins will need to be explicitly stated in their service files. This
> will of course mean more work to verify everything in the KCM, and an
> extra chance of human error. (Screwing something up in a service
> file).
> So, if the KCM does work this out, how should it behave. Should it:
> * not let B be enabled (i.e box greyed out until A is enabled)?
> * give a dialog box asking to enable A when the user ticks the box for B?
> * silently enable A when B is enabled?
> * automatically enable A when B is enabled but inform the user (with a
> KMessageWidget or something) with a button to undo?
> And vice versa if the user tries to disable A while B is enabled.
>
> However, doing it at runtime might be considered a fail on our part by users.
> This will essentially give us the same issues as the first scenario,
> so there's no point in stating them twice.
>
>
> The order that things should run was much more complicated to think
> about. While with a dependancy, it's clear that A has to run before B.
> Other things, are not so explicit. For example, EscapeFilter should
> always run first and we need a way of declaring that.
> Other things are even more fuzzy, like for example, should the
> 'Replace Words' filter run before or after the 'Translate' filter?
>
> We're pretty much at a dead loss for this part.
>
> We also discussed, for actually solving this thing, whether
> dependancies should be declared implicitly or explicitly.
> Explicitly:
>    In the service file, we write that B requries A. This would mean
> the MessageProcessor/KCM would know to enable and load A before B.
> That would mean though, that plugins depend on each other by name. It
> would also mean an extra chance to screw things up - i.e misspelling a
> dependent plugin name and stopping it from loading.
> Implicitly:
>    Because the only way for plugins to interact with each other is
> through properties (which means only one getter and setter), a
> selected list of plugins can be run and rearranged dynamically to the
> required order. This would provide the advantage that if two plugins
> provide the same metadata and the user has either enabled, it'll work.
>    It will also mean there's no chance for us to screw things up by
> making mistakes in the service files, as everything would be
> determined automatically.
>
>
>
> PS: I know for some of these stuff, it might feel like we're blowing
> things out of proportion, but I want to be prepared for any and all
> issues that might arise.
>
> PPS: I wrote this up tired/braindead in the middle of the night, so if
> anything here doesn't make sense, assume every possible outcome ;-P
>

http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKPluginInfo.html#a8b5dc7c6fa266745c0aca91b1fd2c668

and add in your .desktop file:
           X-KDE-PluginInfo-Depends=plugin1,plugin3

The existing KPluginLoaderGuiSelectWidgetThing will already handle
this (I think)

Dave


> --
> Cheers,
> Lasath
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy