Comments 30
Какой формат вы используете для конфигурационных файлов
Отметил YAML. Но в последнее время использую ещё и TOML (такого варианта в выборе ответа сейчас нет)
+4
Какой формат вы используете для конфигурационных файлов
Использую YAML, но с добавкой собственного синтаксического сахара. Плюс особая постобработка.
+1
Если интересно, по ссылке подробное описание: configtree.readthedocs.org
+1
-Нравится ли вам выбранное решение
Слишком двояко вопрос в опросе звучит. «Выбранное решение» — это вы про KTV?
Или нравится ли выбранное мною решение? Как мне моё решение может не нравиться? (разве что этот выбор делал не я сам)
Слишком двояко вопрос в опросе звучит. «Выбранное решение» — это вы про KTV?
Или нравится ли выбранное мною решение? Как мне моё решение может не нравиться? (разве что этот выбор делал не я сам)
0
Использую HOCON https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config
+2
toml еще удобная замена для ini.
+2
Для передачи данных JSON, сжатый в gz. Браузеры понимают, размер маленький. Альтернативные форматы (бинарные etc) слишком медленные на данных порядка 50-200 мегабайт.
0
Ого, медленные? А в чём именно, не подскажете?
0
Смотрите, 100 мегабайт, сжатые в 1-2 мегабайта, скачивается в считанные секунды. Наш бекенд (PHP), чтобы сжать эти 100 мегабайт массива, тратит секунд десять. Итого весь смысл теряется, хотя можно сжать процентов на 20 эффективнее, чем gz.
+1
Использовали CBOR (https://habrahabr.ru/post/208690/) и ещё пару форматов, не помню уже каких — результаты похожи.
0
А ещё браузер на клиенте на полсекунды крепко зависает чтобы из распаковать. С JSON подобного, разумеется, нет.
0
В вариантах голосования нету старых классических S-expressions.
+1
UFO just landed and posted this here
Большинство конфигов в большинстве приложений имеет формат вида:
parameter=value
parameter=value
-1
JSON лично меня устраивает — кавычки, комментарии и типы данных — это нужно не на уровне формата кодирования данных, а на уровне схемы. А вот то, что JSON schema, похоже, не взлетела очень печалит. Если бы она была так же популярна как JSON, заниматься придумыванием 100500 улучшений формата было бы не нужно.
0
Мне кажется, что это, все-таки, про другое. Схемы нужны, но сейчас они обычно описываются в самих модельных объектах. Отдельные схемы нужны, когда формат требует жесткой валидации или используется в большом количестве компонент. Это — достаточно редкое требование в том мире, где, в основном, живёт JSON и компания.
0
Использую свой бинарный формат, который отображается во все остальные текстовые: xml/json/properties/yaml.
Только хочется чего-то более расширяемого и с метаданными.
Только хочется чего-то более расширяемого и с метаданными.
0
Интересное решение. А какие задачи к нему привели?
0
Стыки между разными языками и системами. Простая (проще cbor) передача в бинарном виде (расплата за простоту — увеличение оверхеда по сравнению с cbor). Однозначное отображение на существующие текстовые форматы. Наличие DOM (опционально).
0
Проголосовал за yaml и properties, но ещё использую HOCON и toml, которых в списке сильно не хватает. Странно, с учётом того, что в комментариях к прошлой статье (про KTV) они обсуждались.
0
Sign up to leave a comment.
Нужна ли замена JSON? По следам статьи про KTV