[LC++] Logical/structural question about plugin systems

[Jan Pfeifer]

If you are thinking of the more generic case, where you don't know at compile time which plugins will be available, then you could think that this is a similar problem to the one of package maintenance.

I think of tags that represents aspects of your system. Each plugin could provide the following sets:


- conflict set: plugin cannot be installed if these tags are installed

- replace set: plugin can be installed, but some previous plugin(s) has to be removed first

- provide set: plugin provides these "tags", and can only be installed if no other packages conflicts with this.



You could also add a 

- depend set: plugin can only be installed if some plugin(s) provides these tags



Hope this idea helps :)

- jan



----- Original Message ----
From: Jack Lloyd <lloyd at randombit.net>
To: The Linux C++ Programming List <tuxcpprogramming at lists.linux.org.au>
Sent: Monday, June 11, 2007 2:22:44 PM
Subject: Re: [LC++] Logical/structural question about plugin systems


On Mon, Jun 11, 2007 at 10:34:22PM +0200, Julien Claassen wrote:
> Hi everyone!
>   I'm working on an I/O library. but there's a question. I plan to have input 
> and output plugins, that can be loaded via at runtime via a user-config-file. 
> But there needs to something like an exclusion clause built into the library, 
> because some i-plugins can't work with o-plugins. How best to realise the 
> exclusion matrix? I think it might be best to do it at a global level, because 
> modules/plugins might be added and so we can easily keep track of it.
>   Any ideas, suggestions?
>   Kindest regards
>           Julien
> 

I would say it depends greatly on a few factors, namely how many
plugins you expect there to be, and who is going to be
writing/maintaining them. If it is actually possible to know at
compile time of the main application which plugins will exist and
which ones are compatible with each other, then doing it that way is
certainly easiest. However it's also a bit gross, and more to the
point makes it very difficult for a third party plugin developer to
integrate into your code.

Alternatives that come to mind would be having each plugin know which
other plugins it is not compatible with, or providing whatever
services are needed in the main application so each plugin can inspect
the other plugins and decide on the basis of behavioral differences if
it is possible for it to run. That also allows more complicated
behavior such as a plugin Z that works unless both plugin X and plugin
Y are both loaded, in which case it doesn't, and so on.

-Jack


_______________________________________________
This is the Linux C++ Programming List
: http://lists.linux.org.au/listinfo/tuxcpprogramming List





 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/