'(blog:HappyPeng)

A modular design is a method of conceiving applications which consists in splitting them in relatively small modules, in order to be able to develop, test and debug them individually, which is easier than doing it for the whole application. It is strongly encouraged by object oriented design, so it is the way most of our applications are or try to be developed nowadays. And the next step when you have a modular design is to make your application able to use modules which were not included in its original distribution without modifiying or recompiling its code. These modules are usually called plugins, a word everyone knows because it became widely spread with web browsers.

Adding basic module loading support in an application is usually very easy, because all you have to do is to load the binary object (typically a dynamic library), call an initialization function it provides and let him use the application's functions to add its features. But you already have to make decisions at this point.

First, on how to load the binary object. There is only one method on Unix-like systems, which is dlopen(), but if you want to make things portable or to use higher level APIs, you have to choose between libraries like GModule (GLib), libltdl (GNU), QLibrary (Qt).

Then, you need to choose a common interface your modules will expose in order to for them to be loaded. Typically, they must export a symbol which name and prototype will have to be known by the application.

Finally, the application usually needs to know how to find its plugins (for example it can list the dynamically linkable objects that sit in a predefined directory), how to keep track of the plugins that are available and/or loaded (sometimes in order to provide the user a way to choose which one to load) and even how to manage their configuration.

The other details about a plugin system, like the interface the application provides to the plugins, are much likely to be application-specific, so I won't talk about them. But my point here is that a lot of developers think a plugin system is necessarily entirely application-specific and thus no code concerning can be shared between multiple applications, which is wrong : the needs I just talked about do not need to be entirely rewritten for each application.

GNOME is a desktop development platform, and therefore when a feature is considered as useful for several desktop applications, it should provide a shared library which implements it, and GNOME applications which need such a feature should use nothing but it. The situation today isn't clear. Each GNOME application which uses plugins uses its own system. Some decided to re-use pieces they found useful in other applications, like gedit/epiphany/rhythmbox, but only by copy/paste/modify programming and not by adding a new component to the GNOME platform. Others try to make completely generic solutions, but they're not currently used beyond only a few applications (like Goupil). Finally, older applications still use Bonobo in order to load external modules, a solution I will discuss in further articles.

Other problems are seen in the conception of this kind of plugin interface, such as the fact a lot of different languages are now used in GNOME. A plugin library should care about multiple language support, which seems far from begin as simple as doing it for plain C. Several developers would want their application to be extensible in a language that is different of the one the application was written in ; this involves a more complex loading process and requires languages bindings, something I will discuss in my next post. Some specific needs also exist in the desktop, like the need for an application to stay running while some of its plugins are crashed, like GNOME panel does ; this kind of plugins needs working across IPCs (inter-process communication), so their management is more difficult.

Plugins are the first step towards component systems. Therefore, these problems should be addressed by midtalk with an extensible (itself pluggable) loader which should allow applications to load modules whatever their language or the process they run in is, thus providing the library we currently lack. It currently uses Goupil's DynamicModule to find, configure and load C++ binary objects - it works very well.