Структурированный формат конфигов: YAML vs XML vs JSON

плюсую s-exp

Берешь и проверяешь руками.

Самый удобный вариант: ini-файлы (точнее properties-файлы, но они похожи).

Между XML и JSON предпочту первый, потому что можно создать XML Schema по которому можно валидировать конфиг и в приложении уже быть более-менее уверенным, что в нём что-то относительно похожее на правду. Что за YAML я не знаю и знать не хочу.

потому что можно создать XML Schema по которому можно валидировать конфиг и в приложении уже быть более-менее уверенным

А зачем, нет правда интересно, ведь все равно при сборке приложения нужно будет прочекать допштуки которые или не ложатся на схему или через такие места делаются, что лучше даже не начинать, чтоб коллеги не побили.

Максимум для чего можно притянуть схему это автодополнение в редакторе, при написании конфигов с нуля, аля спринг, без существующего .example c возможными параметрами и комментариями.

Кто что предпочитает из этих трех?

Предпочитаю, чтобы это решали пользователи - нет никакой проблемы поддерживать все 3 формата.

Внезапно, есть JSON Schema. Не пользовался, но не вижу принципиальной разницы.

Это как? Не запомнить что `:` для хешей а `-` для массивов :) ?

К сожалению это именно так. Когда ты их пишешь по 20 штук за день — это один разговор. Но конфиг трогается от силы пару раз неподготовленным к этому пользователем.

«Тут мне нужен список или хеш? А пробел тут не лишний? И так и сяк — всё равно не работает...»

Мне по крайней мере ещё ни разу с первого захода (да и с десятого) не удавалось верно составить структуру (даже для собственных приложений!). И при этом я ещё более-менее понимаю формат.

Но так как другие форматы ещё ужасней, остановился пока на yml.

В конце концов остановился на том, что я сначала дампю конфигурационный структуры в yml и уже это потом использую как пример конфигурации — операция на гландах через 5-ю точку.

Там где от силы пару раз - и джисон сойдет. Ямл имеет смысл когда с этим надо регулярно ковыряться, IMHO.

Long story short: положа руку на сердце, ни один из перечисленных форматов на роль конфигурационного не подходит. Для quick'n'dirty сойдёт. Но по хорошему надо писать свой парсер и свой конфиг под конкретную задачу.

Примеры удачных форматов: pf.conf (и вообще вся линейка OpenBSD конфигов), nginx.

Примеры удачных форматов: pf.conf (и вообще вся линейка OpenBSD конфигов), nginx.

Ты просто к ним привык, если посмотреть свежим взглядом, то они представляют из себя дубовый dsl для описания логики. Причем этот dsl никак не помогает понять семантику, какой датафлоу и что вообще тут происходит без *внимательного* вкуривания документации.

На другой стороне маразма uwsgi со своими ini/xml/yml конфигами, в которых есть условия и циклы.

В качестве примера хорошего конфига можно привести varnish. Они не стали миндальничать и сразу признались себе, что это не конфиг, а программа.

А зачем, нет правда интересно, ведь все равно при сборке приложения нужно будет прочекать допштуки которые или не ложатся на схему или через такие места делаются, что лучше даже не начинать, чтоб коллеги не побили.

Потому что без схемы придётся писать её проверяющий аналог на императивном языке. Это много кода с потенциальными багами (потому что такой код редко хорошо тестят). А чаще всего на это (если мы говорим про тот же JSON) вообще забивают и программа падает с рандомными NullPointerException-ами и приходится ковырятся в исходниках, чтобы понять, что не так пошло (и хорошо, если эти исходники в человекочитаемом виде есть вообще). Схема это тот же код, только в более понятом декларативном виде. Что она не проверяет — можно проверять и в обычном коде, но писать придётся меньше.

Максимум для чего можно притянуть схему это автодополнение в редакторе, при написании конфигов с нуля, аля спринг, без существующего .example c возможными параметрами и комментариями.

Автодополнение в редакторе тоже штука полезная, хотя и менее актуальная, т.к. зачастую конфиги редактируются на удалённом хосте через какой-нибудь vi.

Внезапно, есть JSON Schema. Не пользовался, но не вижу принципиальной разницы.

Комментировать не буду, тоже не пользовался. Распространённость у этой штуки явно меньше, чем у XML Schema. Если позволяет валидировать всё, что хочется, и есть реализация под нужный ЯП, можно и так. Большой плюс JSON-а — он однозначно соответствует стандартным типам и структурам данных. А в XML всё сложнее, приходится или Object Mapper-ы использовать (хотя тут всё опять же из схемы генерируется во многих языках) или через XPath работать, что менее удобно, чем использование встроенных в язык конструкций.

textpb ;)

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

И документация сразу в docstrings в .proto файле в сорцах

А размер библиотеки какой, который за собой тащить придется?

Это много кода с потенциальными багами

Да ладно. Тебе все равно надо бегать по дереву которое выплюнул парсер и максимум что нужно это to_int и to_string. Хотя может в жабке появилась нормальная библиотека для разбора xml конфигов, что-то от commons до сих пор стремные сны.

А если меня это не волнует?

У меня libprotobuf занимает где-то 1.3M

А если меня это не волнует?

Еще бы тебя это волновало, ты же не пользуешься textpb для конфигов.

Почему вдруг не пользуюсь?

Сколько нужно вытащить из гита самого protobuf'a и его зависимостей? Сколько времени все это собирается?

Я серьёзно спрашиваю. Мне действительно интересно.

ssh и tor тебе тривиальные? Марш уроки делать.

Почему вдруг не пользуюсь?

Потому что за примером ты полез не в свой конфиг, а в документашку. Но это конечно так себе дедукция)

ssh

Ок, одно исключение ты нашел.

tor тебе тривиальные?

Не key-value, там достаточно сложная структура конфига.

Ок, одно исключение ты нашел.

Хоть ужом вейся, а ты слился. Туда же postfix, posgresql и wget.

Не key-value, там достаточно сложная структура конфига.

Самый натуральный key-value.

Размер репа? Среди зависимостей кроме libc и libstdc++ вижу только zlib.

А почему я должен свои конфиги постить на форумы?

Хоть ужом вейся, а ты слился.

Давай уж определяться что такое key-value. Потому что любой конфиг это ключи и какое-то значение, даже самый навороченный типа nginx.

Тривиальнейший случай ini. Его я и имел ввиду и мне показалось что и ты. Там только строки и числа. postfix/postgresql/tor не подходят, там значения могут быть других типов.

wget тривиальное.

А почему я должен свои конфиги постить на форумы?

Чтобы как минимум показать как здорово получается вложенные словари и массивы объявлять. Плюс камменты. ТC же хочет структурированный, а ты ini вид с боку привел.

Универсальное тоже надо. Давно пора запилить что-то поприличнее, но т.к. знамя подхватили клоуны, то пока получился только toml.

Размер репа и тулчейн необходимый для сборки и длительность само й сборки. А то зная гугл - обмажут все своими шел-скриптами...

Есть и словари, и комментарии и что угодно

sudo apt-get install?

Распространённость у этой штуки явно меньше, чем у XML Schema.

Наверное в твоем уютном мирке это так, в моем ровно наоборот.

Джисон схему выбирают там, где вместо XML выбирают джисон. Для кучи штук типа api, конфигов и т.п. этого хватает за глаза.

Сагитировать за XML-схему у тебя шансов ровно столько же сколько сагитировать за XML вместо JSON. Их логично использовать парами, исходя из уместности.

Человек, которому на StackOverflow посоветовали добавить кусок конфига не в том формате, будет тебе охрененно благодарен.

Поддерживаю ini.

YAML на порядке удобнее и читабельнее JSON.

«Цитрусовые гораздо вкуснее, чем апельсины!»

JSON — это частный случай YAML. Подмножество.

s-exp, hiccup.

JSON — это частный случай YAML. Подмножество.

Но это не мешает сравнивать их между собой.

YAML на порядке удобнее и читабельнее JSON.

Просто кто-то реально верит в то, что пробелы для человека лучше чем скобки. А кто-то просто привык. Это как спор питониста и жабера. Ну я вот за свою короткую жизнь еще не успел привыкнуть к чему-либо до такой степени, чтобы тупо фапать на это без каких-либо вменяемых аргументов.
Мое ИМХО — скобки гораздо более четко выделяют структуру нежели пробелы. Просто это более наглядно. И во всех редакторах всегда настраиваю пробелы/табуляцию/etc видимыми символами.

В моём уютном мирке про JSON вообще мало кто слышал, честно говоря. XML давным давно во все поля. JSON в последние годы начали применять для передачи данных в JavaScript в браузере.

hiccup
Fast library for rendering HTML in Clojure

Откуда ж вы только лезете.

Есть и словари, и комментарии и что угодно

Покажи хоть код на плюсах, который использует такой конфиг, из доков это не совсем очевидно.

Протухшую версию? :) Спасибо. Посмотри какая версия v8 в той же убунте, например.

json - он няша, легко читается, легко исправляется руками. Парсеры есть под все уважающие себя языки.

JSON в последние годы начали применять для передачи данных в JavaScript в браузере.

https://twitter.com/balancer73/status/707240863915618304

Сейчас JSON — основной стандарт для передачи объектов. И уже давно не в одном только браузере. Почти все современные API стали на JSON.

последние годы
для передачи данных в JavaScript в браузере

Уже лет 5-6 как и далеко не для передачи данных в JavaScript в браузере.

Если писать в конфиг-файл будет только программа, тогда пофигу. Если человек, то из этих трёх XML, чтобы неправильный конфиг можно было по XSD валидировать ещё до запуска приложения.

Ну вот я прямо сейчас работаю в системе, которая интегрируется с несколькими десятками других систем, всё — махровый энтерпрайз, но пишется прямо сейчас. Все интеграции через SOAP веб-сервисы, никакого JSON-а. Сколько работаю — ни разу не видел интеграцию на JSON-е, в 80% случаев веб-сервисы, в 20% случаев CSV/DBF файлы. Такая вот реальность бывает. И что-то мне подсказывает, что подавляющее большинство разработчиков живут в похожей реальности.

XML
Все интеграции через SOAP веб-сервисы

Напомнило:
https://youtu.be/kLO1djacsfg?t=105

Все собирается быстро и просто. я протобуфом пользуюсь как сериализатором. Сборка занимает где-то минуту у меня на ноуте +- может быть. Из внешних зависимостей только zlib, которая, впрочем, необязательна. А еще в 3 версии можно из xml и json парсить/сериализовать.

Во, спасибо (примерно такой ответ я и хотел услышать). Если так, то круто.