Created plugin architecture

[oierlauzi]

I have implemented the following plugin architecture:

• Plugins are represented by the plugin base class. This will be the entry point for plugins.
• Plugins may be statically linked to the core.
• Plugins may be dynamically loaded from a shared object (.so, .dll, .dylib) using the plugin_loader class.
• plugin_manager centralizes all loaded/linked plugins.
• interface_registry centralizes all known interface_managers, which may be expanded by plugins. E.g, xmipp4-em.
• plugins can register their interface(s) and/or implementation(s) on a interface_manager though the interface_registry

Future work:

• Create a façade class that integrates interface_registry and plugin_manager.
• Automatic discovery and loading of installed plugins.
• Add testing

[oierlauzi]

Cannot request multiple reviews @Ratolon also review it please as this is a foundational decision

[MartinSalinas98]

Cannot request multiple reviews @Ratolon also review it please as this is a foundational decision

Indeed, it must be something new

[MartinSalinas98]

I have implemented the following plugin architecture:

• Plugins are represented by the plugin base class. This will be the entry point for plugins.
• Plugins may be statically linked to the core.
• Plugins may be dynamically loaded from a shared object (.so, .dll, .dylib) using the plugin_loader class.
• plugin_manager centralizes all loaded/linked plugins.
• interface_registry centralizes all known interface_managers, which may be expanded by plugins. E.g, xmipp4-em.
• plugins can register their interface(s) and/or implementation(s) on a interface_manager though the interface_registry

Future work:

• Create a façade class that integrates interface_registry and plugin_manager.
• Automatic discovery and loading of installed plugins.
• Add testing

Future work will be developed in this same branch before merging, or are you expecting to merge this branch and later on open a new one to finish this task?

[oierlauzi]

I have implemented the following plugin architecture:

• Plugins are represented by the plugin base class. This will be the entry point for plugins.
• Plugins may be statically linked to the core.
• Plugins may be dynamically loaded from a shared object (.so, .dll, .dylib) using the plugin_loader class.
• plugin_manager centralizes all loaded/linked plugins.
• interface_registry centralizes all known interface_managers, which may be expanded by plugins. E.g, xmipp4-em.
• plugins can register their interface(s) and/or implementation(s) on a interface_manager though the interface_registry

Future work:

• Create a façade class that integrates interface_registry and plugin_manager.
• Automatic discovery and loading of installed plugins.
• Add testing

Future work will be developed in this same branch before merging, or are you expecting to merge this branch and later on open a new one to finish this task?

Whatever it is more convenient. I'd rather create a new branch

[oierlauzi]

I would like to discuss how to test this with you