Project

General

Profile

Task #5091

Switch NFD configuration file format

Added by Eric Newberry 3 months ago. Updated 2 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Core
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The INFO format currently in use for NFD config files is specific to the Boost Property Tree library, instead of being in a standard format. As such, we have had to develop a specific tool (infoedit) to programmatically edit config files in integration tests. Therefore, it would be good to switch to a more popular and standardized format, such as TOML, YAML, or JSON.


Related issues

Related to NFD - Bug #4489: ConfigFile::parseNumber<unsigned>() doesn't reject negative argumentsClosed

Actions

History

#1

Updated by Davide Pesavento 3 months ago

I'd go with TOML.

#2

Updated by Eric Newberry 3 months ago

Davide Pesavento wrote:

I'd go with TOML.

One concern with TOML is that there doesn't appear to be any command-line tool to edit TOML files as of yet.

#3

Updated by Davide Pesavento 3 months ago

Eric Newberry wrote:

One concern with TOML is that there doesn't appear to be any command-line tool to edit TOML files as of yet.

https://github.com/gnprice/toml-cli

#4

Updated by Eric Newberry 3 months ago

Davide Pesavento wrote:

Eric Newberry wrote:

One concern with TOML is that there doesn't appear to be any command-line tool to edit TOML files as of yet.

https://github.com/gnprice/toml-cli

I see. This one must be newer than the article I read saying there was none. This one looks like it's written in Rust, which would add another dependency for the integration tests, although I imagine it would be not terribly difficult to write our own tool in C++ or Python (but that doesn't resolve the existing issue with INFO that I mentioned in the issue description). I also found one written in Node: https://github.com/chrisdickinson/toml-cli

However, since such a tool is available, my preference is also for TOML - I think it has the most readable syntax of the three and can handle nested sections.

#5

Updated by Junxiao Shi 3 months ago

Given all three languages are JSON compatible, you should always provide a JSON schema, and NFD should validate the document against the JSON schema before proceeding.
Using schema validation can eliminate a lot of complexities in parsing, such as "negative port number", "string as port number", "prefix propagation and /localhop/nfd/rib cannot be enabled at the same time".

JSON

There's no way to insert comments in standard JSON.
JSON with comments can be an option.

TOML

Editing TOML on command line doesn't require compiling tools during deployment:

  1. Use tomljson from go-toml to convert TOML to JSON.
  2. Use jq to edit JSON.
  3. Use jsontoml from go-toml to convert JSON to TOML.

jq has Ubuntu packages.
go-toml can be pre-compiled once and anyone can wget them. Go binaries are statically linked and will work on all versions of Linux or macOS.

A drawback of TOML is that, JSON document is not valid TOML document, so that tools that produce JSON must be filtered through jsontoml.

YAML

YAML is a classical configuration format.
Its benefit is that, machine generated configuration files can use JSON, and all YAML parsers will accept them.
However, YAML is too complicated and human can make mistakes.

#6

Updated by Eric Newberry 2 months ago

  • Related to Bug #4489: ConfigFile::parseNumber<unsigned>() doesn't reject negative arguments added
#7

Updated by Eric Newberry 2 months ago

  • Assignee set to Eric Newberry
#8

Updated by Eric Newberry 2 months ago

  • Assignee deleted (Eric Newberry)
  • Priority changed from Normal to Low

In the dev call on March 19, 2020, it was decided that this config format change is low priority compared to other current issues.

Also available in: Atom PDF