How to deal with dependencies between plugins?

[Lasath Fernando]

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

-- 
Cheers,
Lasath