Slashdot Mirror

← Back to Stories (view on slashdot.org)

Learning About Plug-In Architectures?

Posted by Cliff on from the open-ended-coding dept.

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.

2 of 34 comments (clear)

  1. Well, don't... by joto · · Score: 5, Insightful
    Don't design a plugin-architecture. It is a static and unchangeable abomination that must be stopped, that people keep adding incompatible plugin architectures to every program.

    A much better alternative is to offer a standard extension language, such as Python, Tcl, ELK, SIOD, Guile, lua, or even (the horrors) Perl. Now, most anyone of these languages have a plugin architecture, so if for any reason, you need native code speed, it can be done by writing a WHATEVERLANGUAGE-plugin.

    The difficulty of creating a plugin architecture yourself over dlopen, is that you will most likely do it wrong at first try. A little bit less wrong on the second try, and so on... But each minor change you make to the plugin-architecture will probably break almost everything. So it's better to hand the problem off to the scripting-language-implementors...

  2. focus on design principles by jilles · · Score: 5, Informative

    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.

    --

    Jilles