MITK modules (in general any shared library) which register some entities (e.g. object factories, micro services, etc.) during static initialisation of the library currently need to be explicitly linked from a library which is loaded at application or plug-in start-up in order to guarantee the registration of these entities.
This means we currently have artificial link-time dependencies by calling or instantiating some piece of code in the MITK module which needs to register stuff.
With increasing use of the C++ Micro Services library, this scenario will be encountered more frequently in the future, for example specific ToF Hardware devices will be implemented in individual MITK modules and registered as micro service in the modules activator (during static initialisation of the module). Explicit loading of such modules at runtime is needed to guarantee the registration of such module, since no other module has (needs to have) link-time dependencies on these "hardware device modules".
Note that this problem also exists in the CTK Plugin Framework (or for any OSGi or generally plug-in based system). In a OSGi system, this problem is usually solved by using some configuration data (provisioning) specifying the set of plug-ins for the running application.
In the case of the C++ Micro Services, I would propose the following solution:
After the micro services library called the activator of a module, it searches a sub-folder located relative to the current module location and named after the current module for additional libraries to load. All libraries in this sub-folder will then be loaded at runtime by the micro services library, which may in turn trigger loading of libraries in deeper nested directories. The idea of searching specifically named directories for modules (plug-ins) is also used by Qt itself for designer, sql, image formats, etc. plug-ins.
Pros:
- Centralised solution, no changes to current modules needed
- No external configuration data needed
- External modules (e.g. ToF hardware device implementations) can be loaded in the same way
Cons:
- Only one search location per module (if needed, we could create a configurable search path somehow)
- Module link-dependencies to modules in sub-folders not allowed (unless one modifies the search path of the dynamic library loader)
