Comments 30
Какое-то смешивание конфигурации как таковой и схемы ее описания. Разве не стоит их разделить?
Тоже не понял в чем тут логика.
Если у нас в одном месте и валидация настроек и сами настройки, то зачем нужна валидация? Что мне мешает поменять тип port на String и задать его строкой?
[картинка с хлебным троллейбусом]
На практике такие разделённые схемы не работают нормально, замучаешься отлаживать.
Так там же можно сделать модуль и сослаться на него в конфиге. И конфиг будет без всех определений. А сам модуль может лежать хоть в гите.
Уже больше лет 7 во всех своих проектах(на nodejs) в качестве конфига .js файл который тупо eval'ится. Из плюсов: можно не писать ключи в кавычках. Можно писать комментарии и комментить куски конфига при отладке. Можно делать всякие вычисления типа timeout_sec = 60*60*24. И да, многие кто работают с конфигами помнят что 86400 это сутки. А две недели? Если говорить за безопасность, то я не вижу тут значительной уязвимости, тот, кто добрался до конфига сервиса уже может наломать дров.
да, вот за исключение комментов из json-а просто отдельный луч любви
timeout_sec = 60*60*24 - и считаете что это красиво?
ну а так да, всяко лучше yaml ;)
А затем в пароле нужно будет проверять что он содержит заглавную букву, спецсимвол и отличается от предыдущего. Вот это будут лаконичные регулярки
Пример по генерации Java кода странный - да, на выходе получился Java-код, но ведь он бесполезен чуть менее чем полностью - смысл конфигурации в том что её можно изменить, а приложение её прочитает и будет использовать измененные значения, а в сгенерированном коде просто набор констант.
password: String(isBetween(8, 40))
Обычно смысл вынесения значений в конфигурацию в том что эти значения в некоторых ситуациях нужно менять без пересборки приложения. Неужели кто-то в здравом уме хочет иметь возможность изменить требования на пароль после тестирования и сборки??? Да, я понимаю что это пример, но идея что я какую-то валидацию делаю ВНУТРИ КОНФИГУРАЦИИ вызывает некоторую оторопь, получается любой девопс может конфигурацией переопределить логику моей программы, мне потом принесут баг и логи, а я буду бегать и просить еще мне и конфиги стенда отдать, т.к. без них я не могу понять пчм код сделал то что он сделал...
ещё как пример - валидация емейла на регулярках, такая что бы не пропускала admin@localhost и root@127.0.0.1
Зачем такая логика прописывается в конфиге?
Ну вот дали мы этот конфиг тому самому админку локалхоста, который таки хочет вкрячить свой локальный емейл, ради чего пытается поправить регулярку. Что будет?
Политики безопасности могут быть везде разными.
А насчёт лога, к которому требуется конфигурация, то это зависит от подробности лога и того насколько точно там описывается проблема. В данном случае может быть запись типа "нарушено ограничение параметра конфигурации 'password' : больше равно 8, меньше равно 40; текущая длина 6.
Чем-то HOCON напоминает
А мне для конфигов нравится использовать protocol buffers. Думаю, так же неплохо подойдёт любой аналог.
Думаю, причина тут - "фундаментальный недостаток"
Аппле изобрела изобретение:-)
Как то странно видеть декларацию данных и сами данные, когда это по сути файлы настройки, конфигурации, которые сложно представить чтобы были неверно написаны.
Для хранения данных это бы было удобно, да, но для настроек кажется излишним, трудно представить ситуацию, где это может быть необходимо, в плане именно настроек
А мне нравится toml.
Больше всего радует в нём, что на уровне самого формата предусмотрено переиспользование одних параметров конфига в определении других, и то, что прямо в конфиге можно указывать переменные окружения.
Что может быть превосходнее
А комментарии в нем можно ставить?
В текущем зоопарке форматов конфигурации ini/json/yaml/toml/hcl/kdl/xml/etc. + конфигурации на прикладном языке - js/lua/kotlin/python/etc., появление pkl заставляет меня вспомнить классику
Если мне не изменяет память многие идеи уже были в SOAP.
Автор подозрительно молчит про TOML. По сравнению с json/hcl/xml у него есть ряд неоспоримых преимуществ именно для использования в конфигурациях. Он собственно для этого и был создан. Поэтому несравнение нового формата с TOML как минимум небрежно.
Накину еще, мы YANG используем
Pkl — новый язык конфигураций от Apple. Обзор и сравнение с YAML и JSON