...
- Adding configuration APIs adds interface dependencies and APIs are not consistent - need a guide for module configuration APIs
mod-configuration usage
Backend modules declaring mod-configuration usage: https://github.com/search?q=org%3Afolio-org+%22%5C%22configuration%5C%22%22+path%3A%2F%5Edescriptors%5C%2F%2F&type=code
Frontend modules declaring mod-configuration usage: https://github.com/search?q=org%3Afolio-org+%22\%22configuration\%22%22+path%3Apackage.json&type=code
Draft RFC bulletpoints
- mod-configuration shall not be used any more due to security issues
- module is already deprecated, no more configuration settings shall be added.
- Distributed configuration is more native in microsyervice ecosystems and has many pros.
- Distributed configuration shall be preferred
- if a configuration is used by more than one module, and one module is authoritive for this configuration, then this module should hold this configuration. (Example circulation rules)
- A consistant way getting/setting configurations should be established. API endpoints should look like /{module}/{configuration}/{entry} - Julian: Think this is not needed, maybe as a guideline, but not enforced
- Legacy endpoints getting/setting configuration shall get deprecated
- Centralized configuration using mod-settings can or should be used
- by non-sensitive information, that are used by more than one module or are complete independent of any module like locale settings
- settings that are specific to a user
- Configurations for multiple tenants: Craig will talk to Olaminde
...