Я, в целом, планировал публикацию про KTV для ссылки из других статей, чтобы, когда я их опубликую (например, вот эта, про S2) — можно было сослаться и не было бы вопросов, что такое KTV, и откуда оно возникло. Но тема оказалась больная. Поэтому я решил, что нужно немного подробнее рассказать, откуда возникла такая, странная на первый взгляд, идея.

Прикладываю к статье опросы. Помогите мне, пожалуйста, разобраться, в ситуации. :-)

Первая причина — Angstrom Style System


Когда я делал ASS, нужен был формат данных для записи стилей. Я выбрал JSON. По большому количеству причин, главная из которых — очевидность. Формат хорошо и быстро (я сравнивал) парсится, плюс он крайне простой. Это значит, что я могу в те самые строки (у меня их две на пропертю, имя и значение) — запихнуть что угодно и потом это как угодно проинтерпретировать. С одной стороны это удобно, с другой — хрупкость этой системы совершенно неадекватна. Особенно, когда мы работаем со строго типизированным языком вроде Swift'а.

Мне также хотелось, чтобы проперти таки были пропертями, а не просто строками (массивами, ассоциативными массивами), то есть, чтобы их имена — были идентификаторами, а не чем-то-странным-с-пробелами. Это позволит в недалёком будущем, например, написать плагин для AppCode или для Sublime, которые будут проверять корректность их написания и подсвечивать, если что-то не так. Возможно будет автодополнение для @-ссылок, и так далее.

Также мне не хватало нескольких типов. Цвет — самый простой и самый нужный для стайлера, поэтому я с него начал и в KTV для S2. Но в KTV появятся и другие «нативные» типы.

Вторая причина — API


Работая в аутсорсинге, приходится постоянно реализовывать в мобильном приложении разные API. Степень «изобретательности» людей, которые его пишут порой не поддается никакой оценке, это фантастически странные конструкции. И главная причина таких конструкций — JSON. Он позволяет делать что угодно, как угодно. Умные люди стараются ограничить этот полёт мысли, получаются отличные проекты вроде http://jsonapi.org, но мне кажется, что до тех пор, пока форматом остаётся JSON — никуда ничего не сдвинется. Не зря ведь появились Kotlin, Swift, где даже null/nil просто так не присвоить, на это спецтип нужен.

Возьмём, к примеру, получение фида постов, скажем, блога про машинки. Там список постов с лайками, откуда есть ссылки на пользователей, их машины. У одного пользователя может быть 10 постов и 20 лайков. Стоит ли дублировать каждый раз пользователя в посте/лайке (и не только в посте, есть ведь пользователи, залайкавшие посты, или откомментировавшие)? Нет, точно не стоит. Мы это решали при помощи ID и плоские списки объектов, которые при парсинге вставляются, куда нужно. Но, как мне кажется, удобнее эту функциональность внести в формат. Тогда не придется каждый раз изобретать велосипед, будет очевидный способ реализации этой возможности.

Нужен ли новый формат вообще?


Статья показала, что, безусловно, нужно решение всех этих проблем. Поляризация мнений, отсутствие единого направления при решении этой общей проблемы, «а мне и так хорошо» — всё это напоминает мне споры XML vs JSON. Ни в коем случае не хочу сказать, что KTV — это штука, которая станет «следующим JSON'ом», но что-то нужно с этим сделать, чтобы каждый серверный и каждый клиентский разработчик (отмечу, клиенты — это не только веб, но ещё и мобильные приложения и другие сервера) перестал изобретать что-то своё. Слишком много сил тратится на взаимодействие и на изобретение.

При этом я считаю путь, выбранный ребятами на http://jsonapi.org, неправильным в долгосрочной перспективе. Сам по себе он отличный. Я не верю лишь, что удастся заставить следовать этим рекомендациям всё сообщество. Мы ведь такое уже проходили, это XML-RPC, это SOAP. Всё это — попытка зажать свободный формат рамками соглашений. Как показал опыт — не зажимается (точнее зажимается, но исключительно в рамках ентерпрайза). Только новый, жёсткий формат, который используется повсеместно, сможет заставить разработчиков синхронизироваться и формировать API одинаково. Хотя бы простые.

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

Проголосовало 618 человек. Воздержалось 122 человека.

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

Проголосовал 581 человек. Воздержалось 132 человека.

Нравится ли вам выбранное решение

Проголосовало 479 человек. Воздержалось 152 человека.

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

Комментарии (30)


  1. ZurgInq
    09.03.2016 10:27
    +4

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

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


    1. bealex
      09.03.2016 11:11

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


  1. kr41
    09.03.2016 11:53
    +1

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

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


    1. kr41
      09.03.2016 11:57
      +1

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


      1. bealex
        09.03.2016 11:58

        Спасибо!


  1. TimsTims
    09.03.2016 12:09

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


    1. bealex
      09.03.2016 12:15

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


  1. Elufimov
    09.03.2016 12:32
    +2

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


    1. danslapman
      09.03.2016 13:23

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


  1. Gorthauer87
    09.03.2016 13:38
    +2

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


  1. ainu
    09.03.2016 14:52

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


    1. bealex
      09.03.2016 14:54

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


      1. ainu
        09.03.2016 15:01
        +1

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


        1. ainu
          09.03.2016 15:02
          +1

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


          1. bealex
            09.03.2016 15:14

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


      1. ainu
        09.03.2016 15:04

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


      1. ainu
        09.03.2016 15:09

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


  1. Beholder
    09.03.2016 15:54
    +1

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


    1. bealex
      09.03.2016 15:57

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

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


  1. babylon
    09.03.2016 16:31

    Есть ещё JSONNET, а возможно будет JSONext


    1. bealex
      09.03.2016 17:01

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


  1. varnav
    09.03.2016 17:38
    -1

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

    parameter=value


  1. borv
    09.03.2016 21:53

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


    1. bealex
      09.03.2016 22:54

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


  1. speakingfish
    09.03.2016 22:05

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


    1. bealex
      09.03.2016 22:54

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


      1. speakingfish
        13.03.2016 00:31

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


        1. bealex
          13.03.2016 10:52

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


  1. grossws
    10.03.2016 03:42

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


    1. bealex
      10.03.2016 07:40

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

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