Task #1120
closed
Configuration file parser
90%
Description
Develop a configuration file parser.
Section handlers are registered onto the parser.
An existing INFO parser is used to parse the configuration file, and each section is dispatched to the appropriate section handler.
If an unknown section name is found, configuration processing should fail. (similarly, section handlers should fail if an unknown option is found)
Parser API should support std::istream argument type, to facilitate unit testing and usage in ns-3 simulation.
Files
| yaml_support.png (12.5 KB) yaml_support.png | |||
| config_example.xml (2.36 KB) config_example.xml | |||
| config_example.info (1.86 KB) config_example.info |
Updated by Junxiao Shi almost 11 years ago
- Subject changed from Implement ConfigFile parser to Configuration file parser
- Description updated (diff)
- Category set to Management
- Estimated time set to 3.00 h
Updated by Alex Afanasyev almost 11 years ago
Steve, don't take the config file literally, it is just an example of yml and what kind of information should be in it.
We should have several section, one for each manager module and probably a global section.
Updated by Anonymous almost 11 years ago
We basically have two parser options according to the "official yaml site":
- "libYAML (C)":http://pyyaml.org/wiki/LibYAML
- "yaml-cpp":https://code.google.com/p/yaml-cpp/
Here's the packaging situation:
| OS | Version | libYAML | yaml-cpp |
|---|---|---|---|
| OS X | 10.9 | Yes | Yes |
| Ubuntu | 12.04 | Yes | PPA only |
| Ubuntu | >= 13.04 | Yes | Yes |
| CentOS | 6.5 | Yes | Yes |
| FreeBSD | 10 | Yes | Yes |
Updated by Junxiao Shi almost 11 years ago
@Steve can choose an appropriate YAML parser.
NDN Platform Development Guidelines specifies what platforms you must support.
Updated by Anonymous almost 11 years ago
- File yaml_support.png yaml_support.png added
For the sake of clarifying the (failed) table, I've attached an image of our results Alex and I have collected so far.
I do not have access to OS X 10.7/8, so I'm only guessing that both libraries are available through homebrew or ports.
For Ubuntu, what is the official policy for packages available in the official repositories vs. 3rd party PPAs? What is our project's support duration?
Updated by Anonymous almost 11 years ago
- File config_example.xml added
"Duplicate section names and duplicate property names are allowed."
The boost property_tree INI parser disagrees and throws an exception upon hitting the 2nd channel section. I don't think I can get around this (i.e. catch the exception and move on) because the parsing is handled entirely within the property tree's read_ini method. This does not seem to be a boost specific issue because I've found other references that say INI should not contain duplicate sections.
I see our options as:
- Write a custom INI parser that allows duplicates. 2 & 3: Use XML or JSON.
1 is undesirable because it sounds like we are unsure INI is sufficient for what we want in the first place. 2 & 3 are easily parseable in boost via the same mechanism, but it's clear that our file is on human readability and ease of editing by hand.
I received external advice that XML is the better choice because it allows comments and this seems to have (rightfully) become an implicit requirement for the configuration. JSON does not allow comments: http://stackoverflow.com/questions/244777/can-i-comment-a-json-file.
I quickly made an XML file (closely) based off the provided INI file. Please feel free to bash/change it. I just wanted to have something to unblock writing and testing the parser.
Updated by Anonymous almost 11 years ago
- Status changed from In Progress to Code review
Updated by Anonymous almost 11 years ago
- File config_example.xml added
Updated example XML file. Comments appreciated.
Updated by Anonymous almost 11 years ago
- File config_example.xml config_example.xml added
Updated XML example with CDATA for PEM encoded public key.
Updated by Anonymous almost 11 years ago
- File config_example.info config_example.info added
- % Done changed from 0 to 90
Another alternative is to use the INFO format: http://www.boost.org/doc/libs/1_55_0/doc/html/boost_propertytree/parsers.html .
INFO is designed for usage with the specific boost parser we are currently using. It's a bit more readable than XML, but it probably doesn't work with any other existing parser (if that matters). It is trivial to switch the current parser from XML to INFO.
Please see the attached example for an overview of what the config file could look like. The example is based off of the XML structure with some minor changes.
Thoughts?
Updated by Junxiao Shi almost 11 years ago
INFO format looks nice. It's easy to read, and supports #include for larger configuration files.
Updated by Junxiao Shi almost 11 years ago
- Description updated (diff)
- Status changed from Code review to In Progress
20140209 conference call approves to use INFO format for configuration file.
Updated by Anonymous almost 11 years ago
- Status changed from In Progress to Code review
Updated by Junxiao Shi almost 11 years ago
- Description updated (diff)
20140210 conference call decides that configuration parser should fail for unknown section name / option name, because it allows the operator to be notified of a potential configuration error faster.
Updated by Anonymous almost 11 years ago
- Status changed from Code review to Closed
Updated by Anonymous almost 11 years ago
I've made two tweaks the the configuration file's authorizations section format:
- Removed "," after fib privilege. The INFO parser treats each item as a value so it was reading the privileges section as having: "fib," and "stats".
- Changed "face" privilege to "faces" to be consistent with face management namespace.