[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [config-dev] Config path separator syntax in the API
|
The yaml spec does describe an anchor/alias notion 6.9.2. Node Anchors/7.1 Alias Nodes
In looking at Laird's questions, he brings up the issue of knowing what configuration values are in use by a given application deployment. I don't see how that is reasonably knowable from the client side. You can find all specified values if the set of config sources is fixed, but I thought there was a discussion of a key space that could only be known at runtime.
Note also that some configuration languages (including YAML I believe) natively support references, so that must be reconciled behaviorally somehow.
Yes that's a good point. In MP Config, we're using (more or less) the Apache convention of property references as a general reference into the configuration tree, and that does pose many of the same problems... in a properties file of course it's perfectly consistent but in other contexts it seems much more arbitrary (for example in YAML). Also, the syntax was never exhaustively specified in MP Config so behaviors are likely to vary. These details have to be worked out.
Isn't another context in which we have this issue is property references within a config source? Such a reference would need to be resolved against all installed config sources, and so we are back to some universal path specification issue?
On today's call, the last point of discussion was the topic of having an API-level syntax for config path navigation.
The problem is that specifying (at an API level) that the "." character is the canonical path separator character is that it becomes quite inconvenient for use cases where (for example) a configuration path segment itself contains a ".". In fact the same problem applies to other potential candidates for a configuration path separator such as "/" or ":" or ";".
Given this problem and that few actual configuration syntaxes appear to utilize the "." character as a separator (properties and TOML are all that come to mind), I would propose that we do not specify any separator character at an API level and instead make it be purely a concern of the configuration source/parser. At an API level, the key syntax should ideally be allowed to be any string (with the /possible/ exception of the empty string).
To allow easy navigation of the configuration tree by users, I'd instead suggest an API similar to one of the following:
config.get("key1", "key2", "key3").asInt();
config.get("key1").get("key2").get("key3").asInt();
Feel free to follow up here or on next week's call. Thanks!
--
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--
--
