Это такой формат. Вы ведь прочитали всю статью, и прекрасно поняли, что USDS действительно может заменить XML. Вы также прочитали цели публикации. Не пойму, причем здесь юмор?
У вас все еще нет обработки ошибок, юнит-тестов, работы с BigEndian.
А если вы возьмете тот же Protobuf, то все вопросы будут решены бустрее чем за 1 вечер.
Возьмем вот этот метод: Package.WriteString(«SVO»);
Это либо стандартная библиотека какого-то языка, что мешает парсить докумнет на других языках, либо ваша самописная, которая не входит в срок 1 вечер.
Отслеживание трафика профайлером, редактирование конфигов в формате USDS, СУБД может передавать вам результаты SQL запросов в формате USDS: в начале документа схема, далее тонны данных (я плакал глядя на исходный код ODBC-драйвера).
У USDS есть и режим полной бинарности, когда вы не светите схему никому, и везде используются предварительно скомпилированные парсеры (как в protobuf, Bond и т.д.).
Тогда это похоже на решение protobuf с динамическими схемами, которое было описано выше в каментах. Решение в Bond даже лучше, чем у протобуфа, т.к. является частью стандарта.
В USDS второй стороне будет проще, т.к. парсер сам найдет схему данных в бинарном докуенте (при условии что ее туда вообще положили).
Т.е. вторая сторона должна заранее знать, что я в определенные байтики поместил схему, или парсер Bond сам разберется, что схема в потоке есть и найдет где именно она лежит?
(а) tagged-протоколы мало кому интересны, они медленные, большие, годятся только для отладки. Моя библиотека тоже умеет генерить JSON для отладки.
(б) Что подразумевается под «потоком»? Я хочу сохранить бинарный докумнет на диск в один файл, в нем будут и данные и схема, и это потом распарсится?
Тем, что вы дадите им ссылку на сайт продукта и предложите скачать библиотеку, которая не имеет внешних зависимостей и реализована под большинство языков (ах светлое будущее!).
Таки ваш собственный «контейнер» с очень большой вероятностью будет завязан на внушительную часть вашего же исхдного кода.
Взглянем на protobuf2: это изначально не было самостоятельным продуктом, его выделили. В результате для компиляции он тащит еще очень большой объем гугловых библиотек.
Согласен, «читаемость» субъективна. Что касается вашего примера и моего мнения: когда я впервые увидел JSON, я понял его сразу (имея опыт с XML), не обращаясь к документации (но читал документацию, чтобы писать собственные JSON).
Глядя на ваш формат я затрудняюсь разобрать примерно 30% кода. Также есть сомнения, что он компактнее JSON, количество спецсимволов примерно такое же.
SAX в USDS будет реализован очень не скоро, уж больно геморойная тема. Вы конечно можете взять классы InputBuffer/OutputBuffer из моего исходного кода, вооружиться документом «бинарная структура USDS» и писать значения из своих классов непосредственно в бинарный массив, но это прям сакс-хардкор будет.
StAX — крутая штука, я уже думал о ней, надо реализовать обязательно, золотая середина между DOM и SAX.
XPath и XSLT — в далеком светлом будущем, либо может найдуться активисты :)
Это еще один клон Apache Thrift, Protobuf и ASN.1, о чем они прямо и говорят на своем сайте. USDS принципиально отличается от них тем, что вы можете опционально поместить схему прямо в бинарный документ.
А если вы возьмете тот же Protobuf, то все вопросы будут решены бустрее чем за 1 вечер.
Package.WriteString(«SVO»);
Это либо стандартная библиотека какого-то языка, что мешает парсить докумнет на других языках, либо ваша самописная, которая не входит в срок 1 вечер.
У USDS есть и режим полной бинарности, когда вы не светите схему никому, и везде используются предварительно скомпилированные парсеры (как в protobuf, Bond и т.д.).
В USDS второй стороне будет проще, т.к. парсер сам найдет схему данных в бинарном докуенте (при условии что ее туда вообще положили).
(б) Что подразумевается под «потоком»? Я хочу сохранить бинарный докумнет на диск в один файл, в нем будут и данные и схема, и это потом распарсится?
Таки ваш собственный «контейнер» с очень большой вероятностью будет завязан на внушительную часть вашего же исхдного кода.
Взглянем на protobuf2: это изначально не было самостоятельным продуктом, его выделили. В результате для компиляции он тащит еще очень большой объем гугловых библиотек.
Глядя на ваш формат я затрудняюсь разобрать примерно 30% кода. Также есть сомнения, что он компактнее JSON, количество спецсимволов примерно такое же.
StAX — крутая штука, я уже думал о ней, надо реализовать обязательно, золотая середина между DOM и SAX.
XPath и XSLT — в далеком светлом будущем, либо может найдуться активисты :)