The format of the configuration files, the most convenient for editing?

Question

System administration

Greetings, I have a question: what configuration format is most convenient for the administrator for manual editing (well, or just an example of software with an “ideal” config). I used to use nginx/bind like this:
section {
param = value;
subsection {
...
};
};
Then it occurred to me to make an xml configuration for the intended web interface, which as a result does not even read this xml (using a limited set of options organized through a json file).
Therefore, I had a strong desire to switch back to a convenient format for human editing. The only thing I don't understand is how convenient it is to organize "named" sections. In xml it looks like this:

<module name="name">
 <param>value</param>
</module>

But so far I have no thoughts on how to do this in a sectional configuration.

Answer 1

yaml

Answer 2

I would suggest leaving XML, it is now used in many places, administrators are used to it, it is beautifully viewed / edited by any browser / editor that can do markup.

Answer 3

JSON is our everything. I use it in my projects and I'm very happy with it.

Answer 4

Looking for what this config. For example, for Perl programs, I didn’t try anything - the format of the pearl itself turned out to be the best.

Answer 5

JSON is for people, XML is for computers, ini is for Windows;)
Any admin must know all these formats, otherwise, which one is the admin.
But IMHO, since json is more concise than XML and more versatile than ini - it's the most for configs.
As already mentioned above, include support is required.

Answer 6

Config for spam filtering system. The configuration for rmilter, which is used to connect to the MTA in just sections:
bitbucket.org/vstakhov/rmilter/wiki/Documentation
The system itself actively uses lua, but I imagined a lua config and decided that it was too much for an ordinary admin . xml, yaml, json - about the same series: too difficult to edit by an unprepared person. I think that forcing an admin to learn a programming language or to suffer with json / xml is fascism, although yaml is also completely non-obvious for an ordinary admin. Another thing is the configuration in sections, familiar to nginx, dovecot, bind, etc. The only issue is expressiveness.

Answer 7

Personally, the mysql format or, for example, smb is convenient for me, that is, everything is in one config, different sections are separated by blocks
[blockname]
...
...
[bolkname2]
...
...
But in principle, any format is not critical, the main thing is sane documentation.

Answer 8

In general, I tried to consider different options, and most of all I am impressed with the json-compatible format with a number of indulgences and extensions. The main "feature" of the format is the ability to parse json and the modified format with the same parser (and dump the object into different formats in the same way).
1) Perceive the file as a description of the object, which saves us from the top-level {}.
2) Object keys do not require quotes, in addition, instead of ':' it is permissible to use '=', and if the value is an object or an array, do not require a separator at all. So the possible options are:

"key": value

key = value
key = { .. }
key{}
key[]

3) Commas separating values ​​can be omitted or replaced with ';' treat the newline character as the end of the value (if it is not escaped with a backslash), that is, it is permissible:

key1 = value,
key2 = value;
key3 = {}
key4="some long"\
"string"

4) Comments: single-line (// and #) and multi-line (/* */), nesting support is required for multi-line comments, since this is a common action for a configuration file - commenting with nested blocks.
5) Macros: start with '.' and may contain many lines enclosed by {} characters. Applications can register their macros in the parser, expanding the functionality. The built-in parser functions are .include and .includes. The first one simply includes another piece of configuration from a file or via HTTP, and the second one additionally checks the digital signature.
If the format turns out to be convenient for work, then it will be possible to issue the parser as a separate library.

Answer 9

for Perl there is a module Config::Neat , "inspired by nginx configuration files"
similar for Python - pynginxconfig , nginxparser