NFD

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?

"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:

1. 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 example XML file. Comments appreciated.

Updated XML example with CDATA for PEM encoded public key.

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?

20140209 conference call approves to use INFO format for configuration file.

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.