Формат конфигурационных файлов, максимально удобных для редактирования?

Question

[cebka]

Приветствую, встал у меня такой вопрос: какой формат конфигурации наиболее удобен администратору для ручного редактирования (ну, или просто пример софта с «идеальным» конфигом). Раньше я пользовался nginx/bind подобным вариантом:

section {
param = value;
subsection {
...
};
};


Потом взбрело в голову сделать xml конфигурацию для предполагаемого веб-интерфейса, который в итоге этот xml даже не читает (используя ограниченный набор опций, организуемый через json файл).

Поэтому у меня возникло сильное желание снова перейти на удобный формат для редактирования человеком. Единственное, что я не понимаю, это как удобно организовать «именнованные» секции. В xml это выглядит так:

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

Но пока мыслей, как это сделать в секционной конфигурации, у меня пока нет.

Answer 1

[avalak]

yaml

Comments

[rozhik]

Yaml — очень красиво! Но он очень плох приколами с табуляцией. И самое главное, его слишком неудобно использовать на мелких устройствах.
Если конфиг файл нельзя изменить в андроидном терминальчике — то многие такой формат обойдут стороной.

Answer 2

[Владимир Дубровин]

Я бы предложил оставить XML, он сейчас много где используется, администраторы к нему привычны, красиво просматривается/редактируется любым браузером/редактором умеющим делать разметку.

Answer 3

[Q2W]

JSON наше всё. Использую в своих проектах — очень доволен.

Comments

[rozhik]

JSON или что-то похожее на джейсон? В нём же коментариев нет.

[Q2W]

JSON с JS-комментариями, конечно.

Answer 4

[Pilat]

Смотря для чего этот конфиг. Например, для программ на Perl я чего только не испробовал — лучшим оказался формат самого перла.

Answer 5

[KEKSOV]

JSON — для людей, XML — для компьютеров, ini — для Windows ;)
Любой админ обязан знать все эти форматы, иначе, какой из него админ.
Но ИМХО, так как json лаконичнее, чем XML и более универсален, чем ini — для конфигов самое оно.

Как уже написали выше — обязательно нужна поддержка include.

Comments

[cebka]

Если уж добавлять в json всякие вещи, типа инклюдов и embedded lua, то, наверное, стоит как минимум избавиться от его недостатков, типа огромного количества кавычек (что вообще для human editable очень плохо) и излишней лаконичности. Возможно, будет удобен такой вариант:

section = {
 param1 = value;
 param2 = { ... };
 param3 = [ ... ];
};

.include "path|URI";
.lua {
 print('Hello, world')
};

Попытка совместить лаконичность json с удобством конфига (в том числе, и для автоматической генерации).

[rozhik]

В JSON нету комментариев. Так что по крайней мере // + /* */ жаваскриптовские нужно вставить.

Answer 6

[cebka]

Конфиг для системы фильтрации спама. Конфигурация для rmilter'а, который используется для подключения к MTA как раз секциями:
bitbucket.org/vstakhov/rmilter/wiki/Documentation

Сама же система активно использует lua, но я представил себе конфиг на lua и решил, что это слишком для рядового админа. xml, yaml, json — примерно из той же серии: слишком сложно для редактирования неподготовленным человеком. Я считаю, что заставлять админа учить язык программирования или же мучиться с json/xml — фашизм, хотя yaml тоже совершенно неочевиден для рядового админа. Другое дело, конфигурация секциями, привычная по nginx, dovecot, bind итп. Единственный вопрос в выразительности.

Answer 7

[Сергей Петриков]

Лично мне удобен формат mysql или например smb, то-есть все в одном конфиге, разные секции разделены блоками
[blockname]
…
…
[bolkname2]
…
…
Но в принципе не критичен любой формат, главное вменяемая документация.

Comments

[cebka]

ini хорош, если нет вложенности секций. У меня не этот случай.

[Сергей Петриков]

Тогда секциями, вполне привычно и наглядно. XML обилием текста замыливает глаз.

[joneleth]

XML ужасен. Nginx конфиг вполне себе удобен, не знаю зачем вы что-то другое ищете. Отдельно — если не поддерживаете include — обязательно добавьте.

Answer 8

[cebka]

В общем, я попытался рассмотреть разные варианты, и больше всего мне импонирует json-совместимый формат с рядом послаблений и расширений. Основная «фишка» формата — возможность тем же парсером разбирать json и модифицированный формат (и точно также выполнять дамп объекта в разные форматы).

1) Воспринимать файл, как описание объекта, что избавляет нас от {} верхнего уровня.
2) Ключи объекта не требуют обрамления кавычками, кроме того, вместо ':' допустимо применять '=', а если значение является объектом или массивом, вообще не требовать наличия сепаратора. То есть, допустимые варианты такие:

"key": value

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

3) Запятые, разделяющие значения могут быть опущены или заменены на символы ';' символ перевода строки воспринимать как окончание значения (если он не экранирован обратным слешем), то есть, допустимо:

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

4) Комментарии: однострочные (// и #) и многострочные (/* */), для многострочных обязательна поддержка вложенности, так как это частое действие для конфигурационного файла — комментировать вложенными блоками.

5) Макросы: начинаются с '.' и могут содержать много строк, заключенных символами {}. Приложения могут регистрировать в парсере свои макросы, расширяя функционал. Встроенные функции парсера — .include и .includes. Первый просто включает другой кусок конфигурации из файла или по HTTP, а второй дополнительно проверяет цифровую подпись.

Если формат получится удобным для работы, то можно будет оформить парсер как отдельную библиотеку.

Answer 9

[impass]

для Perl есть модуль Config::Neat, «inspired by nginx configuration files»
аналогичное для Python — pynginxconfig, nginxparser