ostis-ai
Config file overhaul
Is your feature request related to a problem? Please describe. Currently configuring components of OSTIS is clunky and most of this configuration happens inside sc-machine. Some parameters are a legacy of previous versions. Config file makes other components FS-dependent on sc-machine. Partially this is solved by #43, but we should look into improving it further in such areas as:
- Clarity and readability
- Extensibility (for future modules or implementations)
- Unification (unified config parser for both C++ code and Python modules/scripts)
- Standardisation
Describe the solution you'd like Most of the discussion about the config file happened upon reviewing #43. Some notable points:
- currently naming of the variables is not unified and is not intuitive
- It's not clear which parameters are required and which are optional. In case they're optional, it's not clear what's the default
- There is no clear separation between configuration of each component. The file should either be unified and used across all instances\parts of the OSTIS-based system (then it would make sense to split the configuration into common parts which are used across most components, such as network/storage/caching/authentication, and then also split it into configuration of optional components, think
[sc-inference]section or something like this).
Describe alternatives you've considered
- We could split the configuration on a per-component basis for more independence between them, but it may become harder to set up a complex system like that. I would not like to do it the way
ostis-web-platformdid before #43 appeared. - We could also leave the old config format if you consider the problems described above non-critical, but we would still have to unify the parser, create some kind of standard and stick to it in the future.
I fully agree with you. Let's discuss a structure of the config file (what attributes it should consist of) and perhaps a work of the parser. It seems to me that it is also worth paying attention to what should be in the config file, and what can be taken out, for example, in CMakeLists.txt.
