LINUX.ORG.RU

Protobuf и никаких строк нигде

phoenix ★★★★ ()

YAML. Меньше всего писать приходится.

Kilte ★★★★★ ()

JSON во все поля. Но иногда приходится кушать что дают.

znenyegvkby ()

Если выбирать именно из этих сортов говна, то JSON. А так, CSS-подобный велосипед.

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

яркий пример logging.config.fileConfig в python:

[loggers]
keys=root,simpleExample

[handlers]
keys=consoleHandler

[formatters]
keys=simpleFormatter

[logger_root]
level=DEBUG
handlers=consoleHandler

[logger_simpleExample]
level=DEBUG
handlers=consoleHandler
qualname=simpleExample
propagate=0

[handler_consoleHandler]
class=StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=

JSON для лохов называется.

Kilte ★★★★★ ()

А почему бы ни все сразу заюзать? Какой язык?

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

deterok ★★★★★ ()

XML уже лет 10 как в гробу и закопан. Если предполагается редактирование человеком, то YAML, иначе — JSON.

anonymous ()

Все варианты гогно. Просто текст или какой-нибудь свой простенький бинарный формат ini подобные или другие свои альтернативи.

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

json, как компромис между читаемостью, поддержкой и машинной обработкой.

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

Вопрос: Зачем его вообще читать?

По хорошему gui морду из которой можно редактировать XML (или json) данные даже писать не надо - она генерируется.

invy ★★★★★ ()

Если писать руками, то выбора нет - YAML.

postman_ ★☆ ()

TOML же моден и молодежен. А в бусте есть такой зверь как INFO.

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

выбора нет, всё тлен

Если писать руками, то выбора нет - YAML

а схему тоже руками будешь писать? для xml (который закопан смузи аналитиками) это не проблема.

type:      map
mapping:
 "company":
    type:      str
    required:  yes
 "email":
    type:      str
 "employees":
    type:      seq
    sequence:
      - type:    map
      mapping:
         "code":
            type:      int
            required:  yes
         "name":
            type:      str
            required:  yes
         "email":
            type:      str
пример схемы для yaml из интернетов, по мне - это кусок говна, потому что я сделал специально ошибку - теперь сам её найти не могу

system-root ★★★ ()

Если нужно редактировать сам конфиг - то только ini, иначе json.

anonymous ()

JSON отметается сразу — в нём нет комментариев, а это очень важно для конфига.

XML — не, спасибо, не надо.

YAML — при всей своей кажущейся простоте очень сложен для написания, особенно при наличии вложенных структур.

Есть ещё 2 кандидата: TOML (ini-like) и HCL (superset json с комментариями и прочими плюшками)

TL;DR: все они ужасны, нормального нет.

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

JSON отметается сразу — в нём нет комментариев, а это очень важно для конфига.

Крокфорд возмущен!

I know that the lack of comments makes some people sad, but it shouldn't.

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

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

Ага, и ты используешь jsmin, не лохмать бабушку. У тебя или тривиальщина в конфигах, для мелкоподелия, или ад и израиль в котором не разобраться.

anonymous ()

Что такое структурированный?

anonymous ()

xml сразу в топку.

json и yaml оба читабельны. Если человеку нужно только читать, то без разницы. Если и писать, то yaml лучше. В json даже коментариев нет.

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

Ага, и ты используешь jsmin, не лохмать бабушку.

Не драматизируй. Если уж так нужно описание на каждый чихкаждое поле, то юзай доп. поля для описаний/хак-методы/etc. Али пару лишних байтов пожалел? Ну и всегда есть json-scheme/любой лишний парсер/etc для особо поехавших. Я лично не жалею байтики, поэтому использую просто доп. поля.
Ну и для совсем мазахистовэкстремалов - конфигурируйте сразу уж скриптами, че уж.

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

Если уж так нужно описание на каждый чих

Драматизируешь здесь ты.

Ну и всегда есть json-scheme

И как она поможет прояснить семантику конфига?

любой лишний парсер

Зачем? Когда можно просто не писать конфиги в json.

конфигурируйте сразу уж скриптами, че уж.

Для питонячих проектов так и делаю.

anonymous ()

Никакой. О XML можно даже не заикаться, ублюдство не годящееся вообще никуда, JSON убог ненужными кавычками и отсутствием комментариев, YAML слишком навороченный.

Самое удобное для сильно структурированного конфига - как у nginx или irssi либо key-value, но намного лучше когда структурированный конфиг не требуется - тогда что-то ini-подобное.

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

но намного лучше когда структурированный конфиг не требуется

Это фантастика, сынок. Рано или поздно требуется и чтобы не бросать родной ini такое начинается.

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

Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.

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

если ты решишь использовать протокол, который передаёт в xml\json много данных, ты без проверки схемы эти данные читать будешь?
обмажешься эксепшенами? для перечисленных «языков» товарищи из altova сделали нормальную экосистему.
а конфиги? как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?

{
  "server": {
    "host": "192.168.10.178",
    "port": 546
  },
  "datastore": {
    "web-proxy": {
      "host": "127.0.0.1",
      "port": 9000
    },
    "default": {
      "host": "127.0.0.1",
      "port": 9000,
      "allow": false
    }
  }
}
а для богомерского yaml что? саблайм?

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

Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.

Сотни тривиальных приложений? Согласен.

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

если ты решишь использовать протокол, который передаёт в xml\json много данных, ты без проверки схемы эти данные читать будешь?

А кто ж мне запретит?

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

как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?

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

anonymous ()

Що, опять?!

anonymous ()

Идеологически рулит произвольный как в Salt Stack.

t184256 ★★★★★ ()

Если требуется ручная работа, то YAML, если только машинная — то JSON.

XML — сон разума, хотя и популярный.

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

Squid например очень тривиальное приложение, да-да-да. А там XML-ем или JSON-ом и не пахло.

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

Squid например очень тривиальное приложение, да-да-да. А там XML-ем или JSON-ом и не пахло.

ini и даже key-value там тоже не пахнет.

anonymous ()

На Луа же.
PS. Что здесь делают пункты 2 и 3, если у нас не обмен машина-машина и зачем кому-то выше понадобилась схема для чтения своего же собственного конфига не понятно. 1 не встречал ни разу, глубокого залегания похоже.

d_a ★★★★★ ()

конфиг nginx самый лучший на свете

mystery ★★ ()

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

Для небольших конфигов использую обычный key=value или ini.

E ★★★ ()

Идеальная программа сама себя настраивает, ей конфиги не нужны )

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

при всей своей кажущейся простоте очень сложен для написания, особенно при наличии вложенных структур.

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

Самое рисковое в ямле - кавычки пропускать, если не знаешь особенностей. Остальное терпимо вроде.

TOML (ini-like)

TOML - это полный звиздец, взлетевший исключительно благодаря личности автора. Глядя на YAML и общаясь с его авторами я вижу, что он overengineered т.к. в него пытались заложить слишком много интересных идей. Глядя на TOML - я вижу что автор вообще ни хера не в курсе синтаксисов и слепил наболевшее по наитию.

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

Френд, для валидации есть json-schema. Не вали в кучу разные сущности. XML это конечно круто, и иногда даже нужно, но для многих типовых задач - абсолютно избыточно и не практично.

Vit ★★★★★ ()

Использовал все 3. Если человеку надо читать/модифицировать, xml. json совсем уж не для конфигов. В yaml вникать надо, поскольку не особо он распространён, но если в конфиге есть подстановочные параметры, то он удобен, емнип.

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

Френд, для валидации есть json-schema

Слышал звон? Там даже 10ой части нет от xsd. Такая же наколенная поделка как и все от фронтменов.

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