Plugins in WOLF: segmenting the library into separate and independent plugins
Created by: joansola
A conversation with Nicolas Mansard at LAAS, about the organization of the wolf library: NM: Nicolas Mansard JS: Joan Sola
NM: Be careful with one last aspect: normally, factories are to be used as plugins, i.e. each new class (or group of classes) implementing the API is in a dedicated .so file, which is dynamically loaded after the main library (containing the factory) is loaded.
JS: OK I see. But what do you mean with 'factories are to be used as plugins' and ' after the main library (containing the factory) is loaded'? This is a contradiction no? You mean that 'each new class (or group of classes) implementing the API' is a plugin, therefore is in a dedicated .so file, but hte factory is in the main library. This is how I understand it. OK?
NM: Yes. I mean: the main library (libwolf.so) should only contain the factory (i.e. API, abstract classes, factory map, plugin loader), and each class (e.g class SensorCamera) should be in a dedicated plugin (sensorcamera.so) to be loaded later. After compilation you would have three objects: libwolf.so (contain the factory) main.exe (contain the function main, is linked with ldd with libwolf.so and call the plugin loader methods -- dlopen). sensorcamera.so (not linked with main.exe in any direction, but linked with libwolf.so, to be loaded explicitely inside the main).