Slashdot Mirror
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.
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...
In talking about a 'plug-in' architecture, from what viewpoint or for what purpose are you looking at the problem?
The first possibility I forsee is that you are developing an application which requires extensibility via third-party modules. In such a case that only design I am aware of (or rather, than I can think of at the moment) is to specify one or more APIs which the plug-in must implement, and then have the facility in your main application to register binary libraries. The application queries the libraries for the API(s) supported, and slots it in somewhere for use at the appropriate point.
The second possibility is that you are developing a plug-in architecture for a language, for others to use in a generic fashion. Your best bet is to study the way this is done in existing languages, and (as many other posters have said) don't do another plug-in architecture for a language that has one.
I had a third possibility in mind, but it seems to have been taken by a pigeon ;)
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
The beauty of binary interoperability systems like CORBA or COM is that if the operating system is written so allow the auto starting of these "little programs" then you don't have to start all of these little programs to make the main program work. DLL's on the Windows plateform are great for this (I don't know about Unix's dynamically linked library system). When your program loads it will request these components and they will be loaded up and then made available for you automagically.
Thinking of CORBA or COM in the manner you are thinking of it will severely limit your uses of these technologies.
Silly Rabbit...Sig's are for kids.