Как стать автором
Обновить

Комментарии 30

Какое-то смешивание конфигурации как таковой и схемы ее описания. Разве не стоит их разделить?

Тоже не понял в чем тут логика.

Если у нас в одном месте и валидация настроек и сами настройки, то зачем нужна валидация? Что мне мешает поменять тип port на String и задать его строкой?

[картинка с хлебным троллейбусом]

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

Так там же можно сделать модуль и сослаться на него в конфиге. И конфиг будет без всех определений. А сам модуль может лежать хоть в гите.

Уже больше лет 7 во всех своих проектах(на nodejs) в качестве конфига .js файл который тупо eval'ится. Из плюсов: можно не писать ключи в кавычках. Можно писать комментарии и комментить куски конфига при отладке. Можно делать всякие вычисления типа timeout_sec = 60*60*24. И да, многие кто работают с конфигами помнят что 86400 это сутки. А две недели? Если говорить за безопасность, то я не вижу тут значительной уязвимости, тот, кто добрался до конфига сервиса уже может наломать дров.

да, вот за исключение комментов из json-а просто отдельный луч любви

timeout_sec = 60*60*24 - и считаете что это красиво?

ну а так да, всяко лучше yaml ;)

timeout_sec = 60*60*24 - и считаете что это красиво?

однозначно лучше чем timeout_sec = 86400

такая ручная математика с временем это костыли. с временем лучше работать через api

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

Такая "ручная математика" человекочитабельнее ) и из неё сразу понятно откуда взялось именно такое значение.

timeout_days = 14 выглядит ещё лучше

Ну или timeout = "14:00:00:00", timeout = "14d"

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

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

password: String(isBetween(8, 40))

Обычно смысл вынесения значений в конфигурацию в том что эти значения в некоторых ситуациях нужно менять без пересборки приложения. Неужели кто-то в здравом уме хочет иметь возможность изменить требования на пароль после тестирования и сборки??? Да, я понимаю что это пример, но идея что я какую-то валидацию делаю ВНУТРИ КОНФИГУРАЦИИ вызывает некоторую оторопь, получается любой девопс может конфигурацией переопределить логику моей программы, мне потом принесут баг и логи, а я буду бегать и просить еще мне и конфиги стенда отдать, т.к. без них я не могу понять пчм код сделал то что он сделал...

ещё как пример - валидация емейла на регулярках, такая что бы не пропускала admin@localhost и root@127.0.0.1

Зачем такая логика прописывается в конфиге?

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

Политики безопасности могут быть везде разными.

А насчёт лога, к которому требуется конфигурация, то это зависит от подробности лога и того насколько точно там описывается проблема. В данном случае может быть запись типа "нарушено ограничение параметра конфигурации 'password' : больше равно 8, меньше равно 40; текущая длина 6.

Чем-то HOCON напоминает

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

Думаю, причина тут - "фундаментальный недостаток"

Аппле изобрела изобретение:-)

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

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

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

Что может быть превосходнее

Что может быть превосходнее

Jinja2, например.

Язык шаблонизации вообще никак не должен быть связан с языком написания конфига. Иначе абстракции текут.

Что может быть превосходнее

эх, закидают меня сейчас помидорами yaml

А комментарии в нем можно ставить?

В текущем зоопарке форматов конфигурации ini/json/yaml/toml/hcl/kdl/xml/etc. + конфигурации на прикладном языке - js/lua/kotlin/python/etc., появление pkl заставляет меня вспомнить классику

https://xkcd.com/927/

Если мне не изменяет память многие идеи уже были в SOAP.

Автор подозрительно молчит про TOML. По сравнению с json/hcl/xml у него есть ряд неоспоримых преимуществ именно для использования в конфигурациях. Он собственно для этого и был создан. Поэтому несравнение нового формата с TOML как минимум небрежно.

А так же нет сравнения с JSON5, который может парсить обычные JSON, плюс добавляет такие плюшки, как 1) комментарии 2) запятую можно ставить после последнего элемента 3) ключи, если они выглядят как идентификаторы, можно писать без кавычек

Накину еще, мы YANG используем

Зарегистрируйтесь на Хабре, чтобы оставить комментарий