Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] [External] : Re: Config path separator syntax in the API
  • From: Tomas Langer <tomas.langer@xxxxxxxxxx>
  • Date: Thu, 26 Aug 2021 16:06:30 +0000
  • Accept-language: cs-CZ, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D84I5RxeL3bOKsR35iePsg2hlALSqBVtigReoXxknEI=; b=PMFZBOH6/la5Ufo7uSxXnZ0N2Gi4zI118yantg0M8C4Nh3lDiUGicmAPbzaAJCbitXOmuzB3/l6GnRQSkhABr6j7TZlJxMohF8k0VZtYRLtfIbDLFdqZSOJ/af90arMQJWcu49H9pD9fZrF1d5A9Kn2N3uTzC7j+ASkL3aB/3wbHxiSA8Z8YxSatx/BTUrkwwPfvaHTWWjvWaYeAaCt/yXa6nqL20WXTTwp0IHDcvX0+tlLJYyShfeIvM2ldVhtnbJQOBMeE1G1EzaPhl0Cs1QWt17dxFtqjt/colS9HruHHYHRhJ962nBU2o8FmCoAwM74Nks4gSde5rV95lDRIZQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y39vFykVI32Fv1HWK2vLXl1dbSnpdJy2nA6kLEMVQRnhHFCxyiQiEmx1hSQDux/5cvjXML01PmlmS0aSQ0LLiXnmMnsSz94hKvgTNLBMNUeADrz/dnFX93Dvfj3sERkqc+2EyoNJOjM+7sATewiQaPaMV4SrHFQcAaT9nLdWfzKC+8Pn4qSC6GBr/FpGg+9kAM265kUF5um1zYcjOhoHQnrQdoDGmfxauWqc5PhMtRFjDG2cOkLVpqgmoNF49d8QH+wTGpIxoKafBFORTcSnmtDyElAvLhuId+BXHJZppveAdu81uoq8x7XdZ+SSBYcxEkbZ78exYWUHDD69/+3kpw==
  • Delivered-to: config-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/config-dev/>
  • List-help: <mailto:config-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/config-dev>, <mailto:config-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/config-dev>, <mailto:config-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHXmootsf5CSioJZEmAQIKC54gUPquF5yWAgAAAcICAAAwAAA==
  • Thread-topic: [External] : Re: [config-dev] Config path separator syntax in the API

As I said on the meeting, I see there metamodel layers:
1. Metamodel of config source SPI - this is where a proper Object model should be provided by any config source parser (properties, yams, xml, json)
2. Metamodels of parsers - for each content type; question here is how much of this should be prescribed by the spec and what can be left to implementations. I can see properties, YAML and JSON defined as part of specification
3. Metamodel of config API - how is it used by the user (and this includes references to other values)

Ad 1 
The proposed model was described by me today, for those who were not on the meeting
Tree structure.
Root node does not have a name.
Each node may be of one of the following types:
- Object Node - contains nested values, lists and/or objects, may contain a top level value
- List Node - contains a list of values, objects or lists, may contain a top level value
- Value Node - contains a value (leaf node)
- Missing - not used by sources, represents a node that does not exist

Ad 2
Mapping of object types should be straight-forward (YAML, JSON) as they natively have tree structures.
Mapping of properties is complicated, I can describe what we use:
 - dot is a tree separator
 - lists are defined as index based (such as server.sockets.0.port=8081, server.sockets.1.port=8082)
 - this basically forbids users from using zero based integers nodes in the configuration (maybe a reasonable price to pay for this?)

Ad 3
First model is the tree structure - in API it would look as “Config.get(“server”).get(“port”)”, or “Config.get(“server”,”port”) to get to a value node
Second model is based on a string notation 
 - I would recommend the dot based notation (e.g. each dot is a separator of a tree node) with capability to escape dots for keys that contain them (such as Config.get(“server.port”))
  The same notation would be used within config sources to reference other nodes using “${server.port}”

I think we should support some simple text based approach to reach a specific node within the tree (both for API and for references), as that is more user friendly then defining a path (similar to what is available in nio - you can use both “Paths.get(“a/b/c”)” and Paths.get(“a”).resolve(“b”).resolve(“c)…

Tomas

On 26 Aug 2021, at 17:23, David Lloyd <david.lloyd@xxxxxxxxxx> wrote:

Note also that some configuration languages (including YAML I believe) natively support references, so that must be reconciled behaviorally somehow.

On Thu, Aug 26, 2021 at 10:21 AM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
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.

On Thu, Aug 26, 2021 at 9:53 AM Scott Stark <starksm64@xxxxxxxxx> wrote:
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 Aug 26, 2021 at 9:38:11 AM, David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
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!
--
- DML • he/him
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--
- DML • he/him


--
- DML • he/him
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://accounts.eclipse.org__;!!ACWV5N9M2RV99hQ!ZouSFBQxhxBWMsIQQ7Gik5gshqyOWuqZ4zijBPDaNe0p9sXZwp86fq3h1DMTnOVKaQ$


Back to the top