This design proposes a plugin system for FOAM that provides for most functionality to be removed to plugins, and the core of FOAM to simply be a plumbing and routing system for plug-in interchange.
Plug-ins will be defined as bundles which contain metadata about the plugin, any data that their plugin requires, as well as the actual plugin code. All plugins will be required to provide their front-end interface as a Python module, but are free to use any implementation method available to do this.
Bundle layout will be as follows:
<plugin>/ cmds/ <namespace>/ ... data/ lib/ scripts/ test/ MANIFEST.json
FOAM will provide access to apis in lib/<api> via the
foam.plugin package, as well as data items. Plugins should not assume that data originally bundled in the data directory will stay there, and should use the proper API to access it.
FOAM will provide two new packages specifically for plugins:
Support for plugins to load named (and versioned) APIs.
Support for using data provided by plugins.
Central notification dispatcher.
Central database API.
Monitoring data collection provider.
Access management tokens.
The core event dispatcher will be a signals-like pub/sub system which will abstract away plugin dependencies - if a plugin would like to receive an event, it can register for such without being concerned whether the plugin that provides this event is installed in the current instance of FOAM.
Database access will be provided via the
foam.core.db API, as a thin layer on top of SQLAlchemy. Table names will be namespaced to avoid collisions and plugins will be required to version their schemas and provide conversion methods to allow ease of upgrading. It is encouraged that plugins do not access database schema from other plugins, and it will not be supported, but it likely will be possible if you are sufficiently creative.
foamctl will be modified to use multiple files instead of the current monolithic interface. Plugins may add commands via the
<plugin>/cmds directory, which will be namespaced at the
foamctl commandline as
<plugin>:<cmd>, for example
The test infrastructure will need to be expanded to be pluggable.