LINUX.ORG.RU

В каком формате лучше хранить конфиги?

 ,


1

2

Сижу, втупляю..
Не хочу велосипедить. Не могу решить в каком формате хранить, генерировать и парсить конфиги своего поделия.

Подробнее: Основной конфиг — иерархия, 3-4 уровня. Затем еще два вида саб-конфигов, разная структура, иерархия, 2-3 уровня.

Условия:

1) текстовый формат;
2) хуман реадабля, и чем реадаблее, тем лучше;
3) минимум зависимостей.

Варианты:

1) *.ini — хуман реадабля 146%, либ как собак нерезаных, да и вообще реализация проста, можно самому навелосипедить и обойтись вообще без зависимостей;
2) JSON — похуже первого в плане читаемости, зато структуру иначе чем написано не распарсишь, либы есть, но что-то они крупноваты по размеру, написать свою ниасилю по времени, придется зависеть от -lfoobar;
3) XML — читается лучше второго, но, зависимость, хотя, libxml уж точно будет стоять на 99% линуксомашин;
4) что-то я такое видел интересное в dovecot'е, похожее на JSON, но читаемее, что это?
5) Еще варианты?

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)

ini канеш, но лучше всё же не велосипедить

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

wat

Если делать все в виде нодов БЕЗ атрибутов, то очень даже читаемый, пример — icecast2

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от intelfx

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

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от mix_mix

TOML

И intelfx, так это какой-то расширенный подвид ini. Таки ini позволяет и массивы запилить через повторения а-ля:

a.b.c = 1
a.b.c = 2
a.b.c = 3

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Если ты про ведроид — на теги посмотри. Если не про ведроид — дай ссыль почитать.

deep-purple ★★★★★
() автор топика

JSON — похуже первого в плане читаемости...

Это наихудший вариант из всех возможных. Более-менее подходят ini, xml (если пользовать его не через задницу как это обычно делают, т.е. большую часть параметров передвать в атрибутах), yaml и protobuf в текстовом представлении. Ну а лучше, наверное, написать что-то своё на основе текстового протобуфа.

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

Реализации ini плохо дружат с иеррархией

Зависит от реализации. Некоторые — вполне себе дружат. https://github.com/toml-lang/toml/blob/master/examples/example-v0.4.0.toml

И да, глубокие иерархии — в приниципе тяжелы для восприятия человеком.

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

глубокие иерархии — в приниципе тяжелы для восприятия

Но ini «вытянут» в ирархии, т.е. она описывается последовательно. Вполне себе воспринимаемо, плюс меньше касяков будет у того кто руками править будет — не нужно следить за индентами и токенами-обертками.

Кстати по ссылке — даже слишком, чем требуется мне.

deep-purple ★★★★★
() автор топика
Последнее исправление: deep-purple (всего исправлений: 1)

бери ini, классика же, json все же лучше читается чем xml имхо, но он плохо подходит для конфигов (разве что не будет необходимости править их руками, тогда лучше его чем ini)

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

YAML

Defective by design. Спецификация yaml не говорит ничего конкретного о том, как же, наконец, получить human-friendly output:

«The final output process is presenting the YAML serializations as a character stream in a human-friendly manner. To maximize human readability, YAML offers a rich set of stylistic options which go far beyond the minimal functional needs of simple data storage. Therefore the YAML processor is required to introduce various presentation details when creating the stream, such as the choice of node styles, how to format scalar content, the amount of indentation, which tag handles to use, the node tags to leave unspecified, the set of directives to provide and possibly even what comments to add. While some of this can be done with the help of the application, in general this process should be guided by the preferences of the user.» ( http://www.yaml.org/spec/1.2/spec.html#id2762313 )

«While some of this can be done with the help of the application, in general this process should be guided by the preferences of the user.» <-- Вот эта хрень, от которой readability зависит на 146%, никак вообще не специфицрована.

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

жсон хуже хмеля потому, что если править руками, то лучше уж хмель, ибо в жсоне будут всякие u\* и руками там уже ничего не сделаешь.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Ну проблема в том - с кем оно ещё подружит?:)

pon4ik ★★★★★
()
Ответ на: комментарий от deep-purple

тогда бери xml, и генерить просто, и читать, и libxml распространена везде. Как бонус - более менее простая правка руками в случае чего. Тот же openbox как годный пример.

ykroop
()

В идеале свой велосипедик. Из готовых универсальных форматов XML без вариантов, если есть хорошая библиотека с поддержкой XML Schema и XPath, всё остальное очень неудобно.

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

YAML

Yaml читаемее json'а, да, но сишной библиотекой для задач типа чтения конфигов не очень удобно пользоваться в отличие от библиотеки json, хотя и терпимо.

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

Из готовых универсальных форматов XML без вариантов

Лучше всего - свой CSS-подобный велосипед.

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

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

А вот из того что осталось — либо реально довелосипедить стандартный ини, чутка его расширив в одном месте и укоротив в другом, либо брать томл и кастрировать. Ну не нужнО мне такое кол-во блекджеков и барышень.

deep-purple ★★★★★
() автор топика

Я последнее время JSON вдруг резко залюбил, но он не очень реадабленький...

I-Love-Microsoft ★★★★★
()

Как по мне, то для таких вещей олдскул лучше всего.

category1.subcategory1.foo=bar
category1.subcategory1.bar=baz
category2.subcategory1.foo=bar
category2.subcategory2.bar=baz

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

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

anonymous
()

может реестр винды подойдёт или вообще бинарщина? ;)

конфиги - зло в общем-то

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

На родном язычке иногда полезно.

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

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

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

тогда не важен формат, точнее какой удобнее,

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

если это эрланг то его родные конфиги (как у ежа примерно)

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

В тегах же — ся. Нужно сделать так, чтобы высеры были читабельны. А так же, чтобы они могли быть писабельны, и, став всерами, скармливаться взад, ну ты понял )) Короче, все главное я описал в условиях в старте треда.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от Legioner

7 чаев этому господину.

Кроме того, храня в XML, плюсуйте в карму конфигов и космос технологий на нем навороченных - XPath, XSLT, XSD / Schema.

Конешне, для json есть нечто похожее (JsonSchema, JsonPath) но как-то поунылее в плане распространенности.

Сам я голосую за хранение конфигов в .Properties-формате! :)
Чиста для разнообразия.

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

Из готовых универсальных форматов XML без вариантов, если есть хорошая библиотека с поддержкой XML Schema и XPath, всё остальное очень неудобно.

Это всё очень хорошо, но читать-писать эту какашку руками очень больно. А уж если кто-то упорется неймспейсами...

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

если ся, то хозяин барин ...

Вообще для вывода текстовый формат, а там штатными средствами преобразовать к нужному виду.

С входными данными конечно больше возни.

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

В случае с ini это костыль, который неудобно читать, и ещё не каждая либа распарсит. А так да, TOML — это своеобразное надмножество ini. Тем и хорошо.

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

Это всё очень хорошо, но читать-писать эту какашку руками очень больно. А уж если кто-то упорется неймспейсами...

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

Неймспейсы хорошая вещь на самом деле. Упарываться ими не надо, но правильно прописанный неймспейс позволит получить на халяву автодополнение в хорошем XML-редакторе. Для сложных конфигов это может быть очень полезно. Много форматов конфигов можно автодополнять без спецредакторов? Для простых, конечно, нафиг не надо.

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

Очевидный scheme, как во всяких gimp|guix, либо JSON. Другого не дано.

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