Skip to end of metadata
Go to start of metadata

Introduction

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.

Bundles

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:

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.

Utility APIs

FOAM will provide two new packages specifically for plugins:

Package

Description

foam.plugin.api

Support for plugins to load named (and versioned) APIs.

foam.plugin.data

Support for using data provided by plugins.

Core APIs

Package

Description

foam.core.event

Central notification dispatcher.

foam.core.db

Central database API.

foam.core.config

Configuration management.

foam.core.monitor

Monitoring data collection provider.

foam.core.access

Access management tokens.

Events

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

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

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 foamctl email:configure.

Testing

The test infrastructure will need to be expanded to be pluggable.

  • No labels