LINUX.ORG.RU

плюсую s-exp

anonymous ()

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

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

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

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

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

anonymous ()

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от Legioner

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

invy ★★★★★ ()
Ответ на: комментарий от Vit

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

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

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

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

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

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от beastie

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

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

beastie ★★★★★ ()
Ответ на: комментарий от beastie

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

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

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

anonymous ()
Ответ на: комментарий от beastie

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от invy

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

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

Legioner ★★★★★ ()

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 файле в сорцах

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

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

invy ★★★★★ ()
Ответ на: комментарий от Legioner

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

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

anonymous ()
Ответ на: комментарий от invy

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

anonymous ()
Ответ на: комментарий от vertexua

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

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

invy ★★★★★ ()
Ответ на: комментарий от vertexua

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

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

anonymous ()
Ответ на: комментарий от slovazap

ssh

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

slovazap ★★★★★ ()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от invy

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

vertexua ★★★☆☆ ()
Ответ на: комментарий от anonymous

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

vertexua ★★★☆☆ ()
Ответ на: комментарий от slovazap

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

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

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

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

anonymous ()
Ответ на: комментарий от vertexua

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

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

anonymous ()
Ответ на: комментарий от beastie

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

Vit ★★★★★ ()
Ответ на: комментарий от vertexua

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

invy ★★★★★ ()
Ответ на: комментарий от Legioner

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

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от invy

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

Miguel ★★★★★ ()
Ответ на: комментарий от E

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

znenyegvkby ()
Ответ на: комментарий от Vit

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

Legioner ★★★★★ ()
Ответ на: комментарий от Hertz

hiccup
Fast library for rendering HTML in Clojure

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

anonymous ()
Ответ на: комментарий от vertexua

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

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

anonymous ()
Ответ на: комментарий от vertexua

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

invy ★★★★★ ()

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

matrixd ()
Ответ на: комментарий от Legioner

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Legioner

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

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

invy ★★★★★ ()

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

alix ★★★★ ()
Ответ на: комментарий от KRoN73

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

Legioner ★★★★★ ()
Ответ на: комментарий от invy

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

anonymous ()
Ответ на: комментарий от anonymous

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

invy ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.