Re: Rise of the Plugins

[Martin Soto <soto informatik uni-kl de>]

On Thu, 2007-05-17 at 18:26 +0200, Vincent Untz wrote:
...
> Moving features to plugins/extensions
> =====================================
...
> Some of the features implemented in plugins/extensions should just
> always be there, and it's useless to disable the plugin/extension. The
> handling of multimedia keys come to my mind (I believe RB is already
> doing the right thing in this specific case and always uses this
> plugin). Plugins/extensions about integration with the rest of the
> desktop are another example.
> There could also be some way to automatically enable a plugin/extension
> when it makes sense.

The problem here is that people don't seem to know what they want their
plugin system for. As you point out, sometimes they just want a
component architecture that they can use to better modularize their
programs. This kind of use should not be exposed to the user at all.
User exposed plugins should offer functionality that is really optional,
i.e.,  a significant portion of the program users is *not* interested in
the functionality, and having it by default would impact those users
negatively (for example, by making the UI unnecessarily complex.)
Unfortunately, many of the plugins I already see in Gnome programs (Gaim
and Tomboy come to mind) don't fit these criteria.

An additional point that nobody has mentioned so far is security. Most
(if not all) plugin implementations already available for Gnome programs
seem to allow for installing plugins in some user-owned directory. This
means that by gaining access to the user's home directory, an attacker
will be able to install code that gets run every time the user logs in:
Ideal for botnets, DOS-attacks, and viruses of all sorts. This is a
point we should consider carefully, because failing to do that may
quickly get us into a Windows-like security nightmare. It is bad enough
that widely-distributed programs like Firefox are already serious
offenders in this regard.

Cheers,

M. S.