#The birth of a python plugin architecture
Q&A
Q. What is the plugin architecture design pattern?
A. The plugin architecture design pattern (also known as microkernel) is a philosophy that surrounds a core application with a number of attachable/detachable modules (plugins). These can be attached and detached in runtime.
The main benefits are the following.
- A core application that needs little to no updating unless it's updated core functionality.
- Functionality can be kept and maintained in small separate modules (plugins). A plugin can be updated regardless of the core application as long as it maintains the same interface to the core application.
Q. What is required of a plugin system?
A. These elements must be in place for a basic plugin system.
- A core system which handles registration/unregistering and activation/deactivation of plugins.
- Some sort of configuration file with info about registered plugins. This could be any type of file for storing basic data i.e. json, xml, yaml etc.
- Plugins using the plugin class as its main component. This ensures interface stability.
My personal belief is that registration and activation should be kept separate.
- Registration should only register the plugin and hence tell the system that its ready for use.
- Once a plugin is registered, it should then be actively activated. i.e. the user activates the plugin for use.
- Activation should not be allowed unless the plugin is registered.
Plugin requirements
- Plugin manager to keep track of plugins and their statuses.
- Plugin registration (installation)
- Plugin activation (activate the plugin)
- Plugin deactivation (deactivate the plugin)
- Plugin unregister (uninstall)
Plugin manager
Plugin registration
What should happen when a plugin registers?
Plugin activation
Plugin deactivation
Plugin un-registering