Decentralized Project Structure
Currently, the AMiRo-Apps project implements a very centralized architecture, where all application and configuration code resides in this single project. A more liberal approach could facilitate a more decentralized architecture, where applications and configurations have their individual projects but can be plugged together using defined interfaces.
First of all configurations should be moved into an individual project, which holds the operating system, middleware(s) and applications as Git submodules, and provides any required glue code. The application project(s) on the other hand, expects certain interfaces (i.e. of an operating system and middleware), which it does not hold by itself. The actual "installation paths" of those should probably specified via GNU Make configuration variables. Any message types used for communication are probably still best defined within the application project.
As result, a configuration project could still comprise multiple configurations with multiple modules each, but also multiple operating systems, multiple middlewares and multiple application projects, and provide all the glue code required for those to interact with each other.
The benefits of such an architecture would be:
- Application and configuration logic decoupled in separate projects.
- Due to this relaxation of dependencies, code development becomes more "decentralized".
- Configurations can comprise multiple application projects and multiple environments (operating systems & middlewares). For the AMiRo plattform, this would allow to unite AMiRo-OS + µRT MCU code and Linux + ROS code in a single configuration project.
Some challenges are expected though:
- Compatibility between OS/middleware expected by applications and actually provided by the configuration.
-> Checking version definitions would be straight-forward, but maybe there is a more elegant solution (e.g. what if multiple application projects expect different versions of the same middleware?). - Transformation of message types between middlewares.
-> two (or more?) alternatives:- Additional mediator applications, which act as bridges between middlewares.
- rather complex
- responsibility is entirely at the configuration
- Applications, message types or middlewares must provide an API to induce and execute transformation code.
- less complex
- requires support by applications and/or middlewares
- still requires configuration to provide and induce such logic
- Additional mediator applications, which act as bridges between middlewares.