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