Most of the applications I write have a common theme, that of processing certain types of scientific data and displaying the results. In nearly all cases, many of the pre-processing steps are the same from app to app, and what makes the apps different is the nature of the samples that were analyzed to produce the data, the details of how the pre-processed data are further processed, and the way in which results are visualized.
There is starting to be a lot of cut and paste style code "reuse". I am thinking that it would be better for me to design a plugin architecture where the common pre-processing and visualization features could be encapsulated into one or more stable plugins. I also like the potential that a plugin framework would give to allow extending the app by simply adding new plugins.
My question involves communication between the framework (that uses the plugins) and the plugins themselves. I can see a choice between two basic options:
- Define well-known interfaces for both the framework and plugins, and have the two communicate using these interfaces and their methods.
- Define signals and slots for both framework and plugins with minimal dependence on interfaces and methods.
(or perhaps some blend of these two).
Some of the things that each plugin may have are:
- Parameters that are used to transform the data
- A GUI for editing the parameters
- Parameter serializing so the framework store or retrieve them
- Commands to add to the framework's menus and / or toolbars
- Plugin-specific GUI elements (dock windows, views, etc.)
- Status reporting for lengthy operations
- A way to interrupt lengthy processing
- Results of the processing (new data to be added to the framework's data model)
- Results serialization
- Result visualization and user interaction with the visuals
- etc.
These seem to fall into two categories of functionality:
- Configuration-related issues that take place when the plugin is loaded / unloaded
- Dynamic issues in which the plugin responds to changes caused by the framework
The Qt examples of plugins (as well as what I have read in books) tends to lean toward the "well-known interfaces" model, with plugins exposing multiple interfaces for various functions. I can see where this would work for exposing features like building menus and editing and serializing parameters.
In my case, some of these plugins might form part of a processing pipeline, where the inputs needed by a plugin may not be available until some earlier plugin has done its work. This implies that a signal / slot mechanism might work better here, where a plugin listens for a signal from the framework that announces availability of required data before it goes to work.
I would like it if the framework knew as little as possible about the nature of the plugins (in particular, where in a pipeline it will act or even if it is part of a pipeline at all).
Does anyone have experience in building this type of a plugin framework, or can anyone point me to a serious example of such a framework?
Should I forget plugins entirely and simply build a library that exposes the common functionality? (Although I really like the appeal of being able to extend the app with new plugins, which you can't do with linked libraries).
Any advice would be appreciated.
Bookmarks