Learning About Plug-In Architectures?

Pimpbot5000 queries: "I've searched high and low for a book/website/etc to get me up to speed on plugin architectures, but so far the pigeons aren't delivering. Where can a programmer go to learn about the different approaches, and their respective (dis)advantages? Most resources I've come across merely point you in the direction of creating plugins for existing projects, or quickly skip over the design phase and get straight to the 'and now you use dlopen()/dlsym() to...' part." I know quite a few plug-in architectures are language specific, but a resource that went over several schemes for each language would be a valuable thing for every coder's library.

Comments

Bamboo

[Gill Bates]

Take a look at Bamboo, which is a plugin (or component) framework.

Bamboo home page

My own design

[Manax]

I've done a 'plug-in' like architecture before, in that case the modules weren't loaded dynamically, but were configured at load time (kinda sorta like winamp, ya gotta reload it).

The key design element method is to make it object oriented, take the class's interface as your API, and bang, you've got a plugin interface.

A little info on my design. I was working on a driver to interface with a custom communication board. Well, we had an original version of the board that we abandoned, a later version which was really used, a test board for that one, and then one or two more.... Each board did communication with a companion board on another device.

My design was to abstract out the UART control, the low-level protocol, the FPGA control code and a couple of other things into seperate interchangable objects. These were objects, but implemented in C, since it wasn't possible to use C++ in the kernel on this platform. Each of those components were configured and plugged into the system at driver load time.

Now, I could have made this slightly different, by pulling out the individual components into seperate modules, loaded as needed, but in this case, that would have been overkill. But the principle is identical.

Back to your original question. I didn't have any books, or other guides to assist with the design. The design fell out of the original needs, after a reasonable amount of refactoring, and a bit of good architecture skill.

In your case, without knowing more details about the application, it's hard to help much. If this is for a general use application, your API will probably be insufficient the first time, so it would be worth your time to think about how you will handle large scale changes to the api. (Are you going to maintain backward compatibility? Are you going to support multiple APIs at the same time? Are you going to add additional specific interfaces over time?) But the core idea again is an OO design where the plug-in is just an object.

focus on design principles

[jilles]

Your question is very vague but I'll bite. First of all you need to understand the design solutions you can use. There are various ways of implenting plugins. Most of them depend on a component model like COM, JavaBeans or Corba. Essential is that you separate the consumer of functionality from the provider of functionality by specifying an interface.

You'll find that the more advanced types of plugin mechanisms are usually implemented in Java. This is no coincidence because Java has a few mechanisms built into the language that enable these mechanisms: reflection (i.e. discovering what methods/properties a class has at run-time), classloaders (load a class at run-time and let it run in a sandbox, destroy classloader to unload the class), dynamic linking (classes are resolved at run-time rather than compile time). An architecture that uses all of this is Jini. Often this is seen as a failed Sun project but the design behind Jini is still very cool.

A final word of advice: don't invent your own plugin mechanism but reuse existing ones.

jEdit

[mjjk2]

jEdit's excellent (and very logical) plugin architecture is extensively described in the documentation. Check the site for more details.