FEATURE: Plugins

[dmerkushov]

The proposed feature is a generalization of #10 .

Problem solved by the feature

No chance for the service developer to plug in into any moment of the nanoservices framework except for the processing of the request.

Some plugin ideas:

• service firewall, allowing or disallowing access to the service based on the connection information
• special logging/monitoring connectors allowing for connecting with certain frameworks

Description of the proposed solution

In general, the idea is the same as for #10:

A plugin is a Linux shared object populating several functions, one for every ablilty that this plugin implements.

An ability itself is a predefined name for its triggering event(s), input and output data. All plugins populating the same ability are queued and called one by one as soon as the triggering event happens. The plugins themselves are allowed to define abilities, too, so other plugins could bind to their triggering events.

Plugins used for a nanoservice are listed in its configuration. The plugin queue for every triggering event is ordered according to the configuration order.

Plugins can depend on each other. Every dependency must be listed in the service configuration BEFORE the dependant.

The framework should have special populated functions to:

• list currently initialized plugins (their names, versions)
• list plugins allowing for the given ability, by its triggering event name
• trigger an event

Plugins should have special functions for:

• plugin name
• plugin version
• check for dependencies
• initialization
• finalization
• list of abilities

The plugins are loaded in order of the configuration, one by one. For every plugin found in the service configuration, the framework loads it in the following order:

1. Check for plugin dependencies. If not successful, continue with the next plugin
2. Initialize using the plugin's initialization function
3. Register the plugin:
   3.1. Add the plugin abilities functions to the end of the queues for the abilities that were listed by the plugin
   3.2. Add the plugin's name and version to the plugin list for the future-initialized plugins to be able to find it

Plugins are unloaded in reverse order of the configuration, using their finalization functions.

Impact on nanoservice development

The service developer is allowed to write plugins that will ease the treatment of special cases of nanoservice development, such as generalization of specific functionality.

Plugging in and out some functions simplifies nanoservice testing in separate environments.

Feature optionality

The feature is not mandatory to use by the developer, but possible.

[dmerkushov]

Priority: A