The plugin API should be low-level enough to allow significant modification of the functionality of the application. This will be necessary to support the open-core model without having to maintain two parallel editions of the codebase – one open and one proprietary. Under this approach, the additional, out-of-core functionality will be implemented in separate non-free plugins.
For example, imagine that the log analysis feature – suppose it is implemented in the rqt_bag style – were to be moved into a plugin.
That would require the plugin API to allow at least the following manipulations:
- Replacing the real PyUAVCAN transport with a fake one that reads data from the log file instead of the network.
- Overriding the wall time provided by the OS with recorded time sourced from the log file.
- Providing the extra GUI controls for inspecting the data in the log file, rewinding the timeline, and replaying the recorded data.
- Possibly patching the user interface here and there.
To ensure that the plugin API is adequate for the task, we should consider implementing the main functional components of the application (the canvas, the global register view, etc.) as plugins, too, rather than directly embedding them into the core. That means that the core functionality would be reduced to some low-level basics mostly devoid of business logic. This concept actually seems commonplace in modern IDEs.
Also, some built-in means of license validation will be necessary for non-free plugins, although this is not a first-order feature.