Ferenc Deak
Ferenc Deak

Reputation: 35448

C/C++ Plugin API design dilemma

I am designing a C/C++ plugin architecture for a solution which comprises of 3 components:

  1. a client level
  2. a core level
  3. a visualization level

All these levels have plugins which talk to the corresponding plugin on the other side (ie: client, disk plugin talks to core disk plugin, and maybe visualization disk plugin, but does not talk to core CPU plugin)

Now, I want to make the creation of plugins as easy as possible, so I came up with the following: The plugins are implemented in shared libraries and loaded on request, and there is a set of predefined functions, such as load, unload, name, etc... the component loads the plugin shared library, looks for these functions, does the work, unloads the plugin.

Now, there is a header file, like:

plugin_client.h:

/***************************************************************************
 *             Methods that are exposed in a client side plugin            * 
 ***************************************************************************/
PLUGIN_LOAD_STATUS load();
PLUGIN_UNLOAD_STATUS unload(PLUGIN_UNLOAD_REQUEST reason);
const char* name();
void do_work();

which makes clear to the plugin developer that he needs to implement the functions above for the plugin to be able to be integrated into the client component of the system.

And here starts the dilemma: For the core component plugin there also should be a very similar (almost identical) header file, and the same for the visualization part. And here comes the question:

How should I handle this situation? 2 solutions came into my mind:

  1. one common header file for all the plugins of the different components, ie: plugin.h and all the functions that can be implemented are in there, with comments, that this method should be implemented in the client, that in the core, that in the visualization component. This has the disadvantage that everything is in one place, and lot of unnecessary things are being made visible to parties not interested.
  2. on header file for each of the plugins, so: plugin_client.h, plugin_core.h, plugin_vis.hand the plugin developer includes which he wants. The plugins have a special function: int plugin_type(); which returns if this is a client, core or visualization plugin. The disadvantage for this is the duplication of information.

Please let me know if you have any ideas regarding how to solve elegantly this dilemma?

thanks, f.

Upvotes: 3

Views: 471

Answers (1)

There doesn't really have to be information duplicate. How about the type-specific headers include a base header, like this:

plugin_base.h:

/***************************************************************************
 *             Methods that are exposed in a client side plugin            * 
 ***************************************************************************/
PLUGIN_LOAD_STATUS load();
PLUGIN_UNLOAD_STATUS unload(PLUGIN_UNLOAD_REQUEST reason);
const char* name();
void do_work();
int plugin_type();

plugin_client.h:

#include "plugin_base.h"
void client_only_function();

And exactly the same for other plugin types.

Upvotes: 3

Related Questions