Нужна ли замена JSON? По следам статьи про KTV

[ZurgInq]

Какой формат вы используете для конфигурационных файлов

Отметил YAML. Но в последнее время использую ещё и TOML (такого варианта в выборе ответа сейчас нет)

[bealex]

Ага, спасибо!

[kr41]

Какой формат вы используете для конфигурационных файлов

Использую YAML, но с добавкой собственного синтаксического сахара. Плюс особая постобработка.

[kr41]

Если интересно, по ссылке подробное описание: configtree.readthedocs.org

[bealex]

Спасибо!

[TimsTims]

-Нравится ли вам выбранное решение
Слишком двояко вопрос в опросе звучит. «Выбранное решение» — это вы про KTV?
Или нравится ли выбранное мною решение? Как мне моё решение может не нравиться? (разве что этот выбор делал не я сам)

[bealex]

Нене, KTV тут ни при чём. Вы все верно поняли, нравится ли то, чем пользуетесь, может быть, выбирали не вы.

[Elufimov]

Использую HOCON https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config

[danslapman]

тоже за HOCON, очень удобный формат

[Gorthauer87]

toml еще удобная замена для ini.

[ainu]

Для передачи данных JSON, сжатый в gz. Браузеры понимают, размер маленький. Альтернативные форматы (бинарные etc) слишком медленные на данных порядка 50-200 мегабайт.

[bealex]

Ого, медленные? А в чём именно, не подскажете?

[ainu]

Смотрите, 100 мегабайт, сжатые в 1-2 мегабайта, скачивается в считанные секунды. Наш бекенд (PHP), чтобы сжать эти 100 мегабайт массива, тратит секунд десять. Итого весь смысл теряется, хотя можно сжать процентов на 20 эффективнее, чем gz.

[ainu]

При этом сжатие plain текста, коим является JSON, занимает мгновения.

[bealex]

Понял, спасибо! Мне как раз и было интересно, где тратится время, это важный опыт.

[ainu]

Использовали CBOR (https://habrahabr.ru/post/208690/) и ещё пару форматов, не помню уже каких — результаты похожи.

[ainu]

А ещё браузер на клиенте на полсекунды крепко зависает чтобы из распаковать. С JSON подобного, разумеется, нет.

[Beholder]

В вариантах голосования нету старых классических S-expressions.

[bealex]

Я не стал перечислять все варианты, их много.

Спасибо, что отметили!

[bealex]

Ага, спасибо, пойду смотреть.

[varnav]

Большинство конфигов в большинстве приложений имеет формат вида:

parameter=value

[borv]

JSON лично меня устраивает — кавычки, комментарии и типы данных — это нужно не на уровне формата кодирования данных, а на уровне схемы. А вот то, что JSON schema, похоже, не взлетела очень печалит. Если бы она была так же популярна как JSON, заниматься придумыванием 100500 улучшений формата было бы не нужно.

[bealex]

Мне кажется, что это, все-таки, про другое. Схемы нужны, но сейчас они обычно описываются в самих модельных объектах. Отдельные схемы нужны, когда формат требует жесткой валидации или используется в большом количестве компонент. Это — достаточно редкое требование в том мире, где, в основном, живёт JSON и компания.

[speakingfish]

Использую свой бинарный формат, который отображается во все остальные текстовые: xml/json/properties/yaml.
Только хочется чего-то более расширяемого и с метаданными.

[bealex]

Интересное решение. А какие задачи к нему привели?

[speakingfish]

Стыки между разными языками и системами. Простая (проще cbor) передача в бинарном виде (расплата за простоту — увеличение оверхеда по сравнению с cbor). Однозначное отображение на существующие текстовые форматы. Наличие DOM (опционально).

[bealex]

Занятное решение. В чём-то мне оно очень нравится. Спасибо!

[grossws]

Проголосовал за yaml и properties, но ещё использую HOCON и toml, которых в списке сильно не хватает. Странно, с учётом того, что в комментариях к прошлой статье (про KTV) они обсуждались.

[bealex]

Вы правы, пожалуй, стоило их включить.

Впрочем, там многие форматы обсуждались. Чтобы разобраться, какие популярны, какие нет — я и сделал это голосование.