?

Log in

No account? Create an account
усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
When in doubt, write a DTD
усы2
tonsky

Хочу поговорить про схемы. Поводов два — во-первых, Cognitect (company behind clojure/core и Datomic) выпустила Transit, протокол сериализации данных, и в нем не предусмотрено out-of-band схемы. Точнее, повод это HackerNews тред, в котором пророчат будущее за протоколами с явной схемой. Во-вторых, мне на глаза попался сборник HTTP API guidelines, и там безапелляционно требуют прикладывать машинно-верифицируемую схему к вашему API (и заметьте, что никак не мотивируют это).

Преимущества иметь схему заранее — быстрый парсинг. Конечно protobuf/thrift парсятся быстрее JSON, как бы ни оптимизировали последний. Подход performance first затуманил взгляд многим тысячам программистов, ведь когда слышишь «зато мы можем кодировать 120Mb/sec», из рассмотрения уходят любые другие факторы. Включая, к сожалению, и вопрос «а наберется ли у нас эти 120 Мб в секунду»?

Все следующие преимущества проходят по разряду спорных или даже маргинальных. Возможность запустить механический валидатор по возвращенному документу это преимущество уровня статической типизации в ЯП — уберегает от самых тривиальных ошибок вроде опечаток (эх, если бы все мои проблемы были такими простыми!), но никогда не поможет отличить смысловые ошибки вроде перепутанных min и max. Плюс, если статическую типизацию хотя бы ясно когда и как запускать, то когда валидировать схему не очень понятно. На каждый пришедший документ? Выборочно? В режиме разработки только? И что делать, когда документ не прошел валидацию? То есть, непонятен банальнейший сценарий использования, последовательность действий. В XML был механизм DTD, например, валялись в документах ссылки на схему, или неработающие, или устаревшие. Чёт не прижилось.

Дальше по нарастающей идут сложности, а не преимущества. Например, как описать вариабельный ответ? Скажем, если в запросе я указываю, какие поля хочу видеть в ответе. Или если ответ это список разнородных ресурсов. Или я хочу выразить «присутствовать должно только одно поле из вот этих трех». Это или усложняет язык описания схемы (и тогда все на нее забьют), или поднимает вопрос «а зачем нам схема, если она даже половину синтаксических ошибок не ловит»?

Есть еще проблема миграции. В какой-то момент по системе будут летать сообщения хорошо если двух, а то и пяти-шести версий (если лень, скажем, 5 Тб базу конвертировать в новый формат). И ладно если это всё внутри, как-то можно с этим справиться (переучиваем сначала приемник, затем передатчик). А внешний клиент, который сидит на схеме X, и вдруг начинает получать сообщения в формате X+1? Да, часть простейших миграций можно предусмотреть, но когда содержимое документа парсится на основании чего-то снаружи, отстающий клиент рано или позжно даже прочитать сообщение не сможет. То есть проблема возникнет не на этапе «я не знаю что мне с этим делать», проблема возникнет еще на этапе чтения бинарного потока, когда никакую логику/эвристику пользовательский код еще не может применить.

Страдает и программист, потому что сообщения для него непрозрачны. Браузер, скажем, может распечатать JSON, а вот protobuf — не может, и нельзя написать универсальную тулзу-просмотрщик protobuf-а. Потому что схему надо как-то доставлять к месту где она нужна, отдельно от сообщения, а это неудобно.

В идеале, конечно, иметь схему хорошо и правильно. Но дальше мысль останавливается. По мне так, когда нет ясного сценария «как я это буду использовать и какую получу выгоду», это вещь бесполезная. Когда-то люди верили, что нужно все аннотировать в машинно-читаемом формате, и компьютеры сами будут находить друг у друга API и разбираться, как разговаривать по ним (WSDL куда-то сюда метил). В принципе, проаннотрировать, получается, можно, а вот сделать такой компьютер, чтобы разобрался, оказалось непросто. В итоге все API прекрасно существуют с документацией в человеко-читаемом формате, а вся семантика проходит через программиста. SkyNet если и зарождается, то очень медленно.


  • 1
Хикки последовательно реализует все свои эротические фантазии. Вообще in-band это круто, хотя вживую ни разу не видел. JSON то на деле тоже out-band формат.

Ты просто смотришь на мир со своей колокольни. Сериализация это не только обмен между клиентом(браузером) и сервером, есть еще задачи хранения данных, когда более компактное представление позволит и хранить больше и читать/писать быстрее. Есть всякий телеком/RTB/HFT, где разница в скорости сериализации/десериализации между бинрным protobuf и текстовым json будет очень критична. Для всего остального, конечно же, есть JSON.

У Тонского всегда так. Ту узкую область, которой он занимается на работе, он обобщает до всего мира.

без темы (Анонимно) Развернуть
(Анонимно)
Dtd - немодно. Для структурной валидации XML лучше использовать xsd, он свежее, яснее и, к тому же, сам является подмножеством XML в отличии от dtd.
Для нетривиальной валидации XML можно использовать Schematron. Схематроновских правил при этом не должно быть много. Если у вас в запросах к API среди параметров серьезная вариативность, скорее всего API нуждается в упрощении.
Но схема должна предоставляться провайдером сервиса, по-моему, это логично!

> Конечно protobuf/thrift парсятся быстрее JSON, как бы ни оптимизировали последний

Чуваки из rehinkdb перевели протокол общения клиентов с сервером с protobuf на json мотивировав это как раз тем, что в реальной жизни json часто оказывается еще и быстрее, просто потому что на него дрочат на всех платформах.

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

Самый главный плюс схемы - это документация: а) Я вижу, что мне нужно отсылать серверу, б) я знаю, что сервер пошлет мне в ответ. Причем документация на привычном, строгом и унифицированном языке.
Без схемы же люди обычно тратят время и городят какую-то херню на естественном языке, и это еще дай бог, что она не устарела. Я смотрел как-то раз API одноклассников, так это пиздец был: документация была очень сумбурной и нечеткой, я часа два втыкал, в каком формате что отправлять, какие поля за чем идут и т.п.

Добрый день!

Простите, что вмешиваемся.
Сейчас документацию API Одноклассников можно посмотреть по ссылке http://apiok.ru/api/
Написано очень понятно и доступно.
Если есть конкретные замечания, мы с радостью их выслушаем.

что значит - валидировать схему? против чего?

Разумеется, self-descriptive data это единственный возможный путь, а сторонники performance first — латентные мазохисты, которых нужно как следует выпороть, чтобы они получили наконец удовольствие и не лезли в программирование.

Я нисколько не шучу.

Да и вообще любые экстримисты не лезли бы в программирование.

Иерархия протоколов

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

Предлагаю вариант последовательного опознавания протокола. В отличии от OSI уровни развиваются к середине.

tunnel_21_v_0.5

http://ru-philosophy.livejournal.com/1543719.html

Так а вокруг чего разговор идет? Что нет единого формата сериализации, который бы удовлетворял всех?

Так блин, это очевидно уже лет 40 как, если не больше. Поэтому и делают разные протоколы для разных задач. Кому-то нужны высокие скорости сериализации/десериализации, кому-то нужны малые объемы упакованных данных, кому-то легкая и быстрая валидация синтаксиса и семантики, кому-то удобство чтения человеком и т.д.

Если есть желание чуть-чуть войти в тему возможностей продвинутых систем сериализации, то есть хорошая книга John Larmouth "ASN.1 Complete". Книга большая, но первые несколько глав дают общее впечатление, а дальше можно читать выборочно мелкими порциями. В частности, будет лучше понятно, почему нужны разные форматы данных, как реализуются точки расширения форматов (та самая проблема новых версий) и пр.

Я тут вброшу инфы из нашего уголка мобильных банков. Мы сейчас как раз живём без машиночитаемой спеки на JSON API и это неприятно - один и тот же код дублируется и для сервера и для андроида и для iOS. А когда-то ещё Windows Phone случится. А его (код) можно было бы генерить по спеке. И это не только сериализация/десериализация: модель данных, абстракция API для конкретной платформы и пр. При этом ни кто не отменял нормальную человеко-читаемую документацию. Зачем из крайности в крайность? Тот же protobuf хорош не только бинарностью, но и наличием не сильно сложной (в плане парсинга) формальной схемы из коробки.

А про производительность - на мобилках всё, что вы делаете жрёт вашу батарейку. А ещё и бабло (причём очень нефигово), если это трафик в роуминге. Поэтому байты имеют значение. Про читаемость JSON из коробки - опять же зависит от задачи. У нас эта фича нужна программисту один раз в месяц в течение 4-х часов при подсосе к новой функции на сервере. Да и то не всегда. Всё остальное время она никому не нужна - тупо жрёт трафик и батарейки пользователей. Причём, вроде как, логичный и очевидный довод "разбирать логи - удобнее" тоже не работает (я сам удивился, на самом деле). От юзеров (у нас >70К активных установок приложения) логов не приезжает. В процессе же разработки порядки востребованности указал выше.

Тут ещё важно уметь взглянуть на дело с точки зрения размена: что нам важнее, удобство программиста или профиты для юзера? Если слишком мало первого - будут баги, мало второго - гундёж в Google Play / App Store (а в случае игр, так тупо uninstall и уход к конкуренту - там всё просто из-за огромного выбора).

(Удалённый комментарий)
Связь такая: мы размениваем 4 часа в месяц удобства программиста (вместо 8 часов ковыряния бинарного говна на манер protobuf, хотя при должном старании и там всё ок) на батарейку и трафик у юзеров. Зависит, конечно, но выглядит странно, когда юзер "платит" за неосиляторство инженера. Но тут, повторяюсь, вопрос тонкий, так как удобство может влечь меньшее число багов.

Схемы нужны для кодогенерации в C++ и Java.

Остальное — притянутые постфактум фигульки-свистульки.

В моём понимании, от схем очень простая выгода - они позволяют рассуждать о предмете в отсутствие самого предмета. У нас был проект под WebOS, фронтэнд которого общался с бекэндом посредством JSON. Структура запросов в основном задавалась командой фрондэнда, и, пока не написали схемы на запросы, была масса недопонимания вида "а зачем это поле, что в нём и как". Конечно, структуру запросов можно было и словами записать. Но схемы компактнее и строже.

Опять же, по опыту этого проекта, подход "вот есть код и из него и понимайте, как оно должно работать" был бы неэффективен по ряду причин, в первую очередь в виду географической отдалённости команд фронтэнда и бекэнда, и в силу культурных различий - бекэнд был на С++, а фрондэнд - на JS.

holland casino online gokken casino online gratis ruleta casino online regalo sin deposito

(Анонимно)
http://www.power-roleplay.com/forum/index.php?topic=246922.new#new
http://forum.maarch.org/viewtopic.php?f=29&t=3307
http://www.rpg.buzz/forums/viewtopic.php?f=11&t=39278
http://haustier-forum.info/viewtopic.php?f=10&t=26492
http://conchi.hopto.org/Forum/viewtopic.php?f=9&t=86523
http://maddenpcmod.123forum.co.uk/viewtopic.php?f=24&t=10056
http://paniqo.org/viewtopic.php?f=67&t=83222
http://medslat.com/forum/viewtopic.php?f=50&t=288051
http://eurovetsworld.com/Forum/viewtopic.php?f=7&t=112301
http://dmitrovka139.ru/viewtopic.php?f=2&t=311032
http://volleykem.ru/forum/viewtopic.php?f=9&t=11485
http://umnikizdes.ru/topic550699.html
http://robertrudd.com/sacforum/viewtopic.php?f=11&t=17755
http://forum.autoecolepratique.com/viewtopic.php?f=6&t=184339
http://stitchfanclub.com/forum/post/409934.html#409934

казино рояль смотреть онлаР

(Анонимно)
http://paniqo.org/viewtopic.php?f=73&t=91824
http://forum.technicaldiving.ie/index.php/topic,141803.new.html#new
http://doletzkaya.ru/forum/index.php?topic=178524.new#new
http://leslapins-gamer.fr/forum/viewtopic.php?f=21&t=167570
http://www.speedtouchforum.de/viewtopic.php?p=31531#31531
http://forums.orangineers.com/viewtopic.php?f=9&t=24036
http://forum.aspirinby.org/viewtopic.php?f=112&t=1312270
http://www.alcoforum.com/viewtopic.php?f=5&t=2585
http://www.ausvoters.org/viewtopic.php?f=16&t=222147
http://forums.orangineers.com/viewtopic.php?f=8&t=22943
http://classic-car-talk.com/viewtopic.php?f=9&t=28126
http://www.factioncraft.cz/forum/viewtopic.php?f=13&t=207381
http://www.trinkwasserforum.at/viewtopic.php?f=9&t=12248
http://dnd-solutions.com/Tesla/phpBB3/viewtopic.php?f=4&t=250211
http://stxoutdoor.com/forum/viewtopic.php?f=7&t=359701

  • 1