Open oschuene opened 3 years ago
@oschuene
We already have an abstraction here called roudi_config_file_provider.hpp
. So maybe we can specify the task Implement manifest reader
further with Implement roudi_config_json_file_provider.hpp
.
Could you please specify what you mean with manifest? Is it a config file like the roudi config file which is currently present only in json? If it's not and you would like to parse further settings it may makes sense to start with a design document.
Took up the proposal by elfenpiff. Yes it's nothing else than the roudi config I want to parse.
While it's perfectly fine to have additional provider for configurations, we should not easily add them. At first we need examine the reason for this. If you want to be able to configure RouDi by JSON because you are a big JSON fan is a valid reason in my point of view. If you want to use JSON because our current TOML parser has issues with a fuzzer it should be checked if there is a better TOML implementation which fits our needs. Keep in mind, having multiple configuration options has a maintenance cost. The advantage of TOML compared to JSON is its design as configuration format contrary to JSON which is a data exchange format and therefore doesn't have such things like comments. Since tiny-json is a C library, have you looked at https://github.com/cktan/tomlc99?. As candy on top, it also runs against two large test suits with complex configurations. If the reason for JSON is just the fuzzer, please consider an alternative TOML implementation instead on integrating a completely new method of configuration. If you are a JSON fan, then just ignore my gibberish.
Brief feature description
Parallel to the Toml Config File Provider Reader a new Config File Provider using json as format shall be created.
Detailed information
The new Config File Provider shall use tiny_json as library for parsing the config file. This library has a better liability when checking it with a fuzzer test than the toml lib currently used.