(Sep-28-2017, 07:22 PM)nilamo Wrote: I'll take the opposite position: I hate json. It's better than xml, but that's not a very high bar. They're both read-only languages.
In my opinion, if a config file is meant to be edited by humans, it should be fairly loose in what it allows, and be pretty obvious on how to structure it. To that end, I like yaml and toml. Even .ini files aren't bad.
json just has too many weird quirks which makes it unsuitable for editing by hand, like how it's illegal for the last element in a list to end in a comma. # invalid json:
[
"item1",
"item2",
"item3",
]
i don't
hate json, but i do agree with "it should be fairly loose in what it allows, and be pretty obvious on how to structure it." i have encountered yaml once before and didn't like it. i have not heard of toml bafore. i currently use python as my config language.
i think there is a difference how some programs and humans (want to) handle configuration:
1. the program interacts with the human to get configuration settings and store them in the chosen format. some programs (their developers) want to have that file be human readable and/or editable in a limited way where it is easy to change single things like a number (3.15159), symbol (Pi), time duration (1h22m30s), or file path ("~/images/big-bg.png")., but not structure. and some programs (their developer) just give up on human editing and use a binary format. this decision can easily vary by language, for C/asm and maybe C++ the easy choice is binary, for Pike/Python the obvious choice depends on the tools that are known.
2. the program expects the user to create a "configuration" or "working data" from scratch either with a text editor or some other program. one example in this category is
bind, the DNS server, which has both the the list of domains and zone files as working data.
i like to use Python source code itself as the config language because it can be simple or complex at the choice of the human who codes it. the last element in a list can end in a comma, etc. i use it as category 2 but also have a nice tool to make it work in category 1.
i think XML is intended for category 1 and/or "working data" not created by humans, like a database transfer.
i think JSON falls in the middle.
i've seen some variations on .ini format.
the format
bind (the DNS server) uses for configuration looked familiar from my mainframe days (VM/CP/CMS). but back then i coded almost entirely in Assembler or Rexx. it would have been nice to have had Python back then.
i use a few tools i created (long before i did Python) to help create DNS zone files for
bind.