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. Re:Runtime aggregation. by foobar104 · · Score: 4, Insightful

    Well, assuming that you absolutely must design a plugin system, lookin into some runtime aggregation systems (COM or CORBA depending on your platform and needs). That's basically with these techologies are for.

    Hmm... I don't think I agree.

    When I think "plugin," I think of an application loading and executing some code from a DSO or whatever at run-time.

    When I think "CORBA," I think of two running applications communicating with each other at run-time.

    They're fundamentally different things. If you were to design your plug-in architecture using CORBA, you'd have to have your programmers build little applications that would have to be started and to run alongside your main app, just so your main app could make remote calls to them. Seems kinda silly to me.