Re[18]: Is SOAP simple? - Философия программирования

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Здравствуйте, Курилка, Вы писали:

К>>А может JSON?

YKU>И, простите, где принципальная разница? Откуда водуг возьмётся ускорение на порядки?

YKU>Да и ситуация знакома до боли. "Вот какая простая и классная штука!" Угу, пока простая — она классная. Потом начнётся(как там в обсуждениях уже и заметили): "мы ходит дату", "мы хотим время", "мы хотим булевские типы"... И появится дополнительно описание типа. Потом будет еще "мы хотим..."

YKU>В результате получится еще один XML.

По этому поводу неплохо написано здесь
XML — не панацея, также как и JSON

Каждому гвоздю — свой молоток

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Никто не прозреет, это и так понятно,

не понятно

YKU>Только что вы будете делать с совместимостью всего зоопарка, который сейчас худе-бедно, но понимает друг-друга через XML? Пересаживать на бинарные пакеты? Узбеков.

странно...повсеместно используются форматы PDF, GIF, JPG, ZIP.....
и все друг друга как нестранно понимают.

чего такого уникального в XML?
убогий текстовый формат, средства для визуализации которого широко распостранены? и этот микроскопический плюс способен перевесить гигантские затраты на преобразование из бинарного в XML формат крайнене эффективно использующий каналы обмена информацией, чтобы потом обратно преобразоват в бинарный вид пригодный для дальнейшей обработки?

и вот ЭТО корявое все на что сподобились лучшие IT — шные умы? вот уж точно

Беседы на сонных кухнях,
Танцы на пьяных столах,
Где музы облюбовали сортиры,
А боги живут в зеркалах.
Где каждый в душе — Сид Вишес,
А на деле — Иосиф Кобзон...

(С) Алиса

неужели не очевидно, что правильное направление эволюции это принятие стандарта бинарного обмена (достаточно выбрать один из уже созданных) и распростронение средств его эксплуатации.

это так сложно????

Тычеблин wrote:
> чего такого уникального в XML?
> убогий текстовый формат, средства для визуализации которого широко
> распостранены?
Покажи альтернативу.

ASN.1 — не подходит из-за большой сложности.
JSON — слишком прост и сам с кучей недостатков.

Вот сейчас редактирую mapping'и Hibernate'а, они в XML. Так мне IDEA
подсказывает имена тэгов, на лету валидирует ошибки и дает autocomplete
по DTD.

Или еще пример — я использую XSLT для преобразования POM-файлов из
Maven2 в проекты IDEA.

Просто некоторые не понимают что позволяют технологии, сделанные на базе
XML.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

C>Тычеблин wrote:
>> чего такого уникального в XML?
>> убогий текстовый формат, средства для визуализации которого широко
>> распостранены?
C>Покажи альтернативу.

а без показа альтернативы очевидность сказанного сомнительна?
не очевидно что бинарные данные прекрассно сериализуются, и передаются? и что промежуточное преобразование в текстовый формат это исключительно плата за дурость и невозможность договоритья?

C>ASN.1 — не подходит из-за большой сложности.
C>JSON — слишком прост и сам с кучей недостатков.

никто на этом ненастаивает.

C>Вот сейчас редактирую mapping'и Hibernate'а, они в XML. Так мне IDEA
C>подсказывает имена тэгов, на лету валидирует ошибки и дает autocomplete
C>по DTD.

это такая особая магия проистекающая из сути XML?
или это банальный инструмент который в частном случае работет с этим форматом.

C>Или еще пример — я использую XSLT для преобразования POM-файлов из
C>Maven2 в проекты IDEA.

C>Просто некоторые не понимают что позволяют технологии, сделанные на базе XML.

Просто некоторые непонимают, что бывают технологии, а бывают инструменты для работы с технологиями.

А я например каждый день использую файловую систему по сути бинарное хранилище, создаю, удаляю открываю, закрываю файлы и пересылаю их по сети.

слушаю mp3, смотрю AVI, MPG, обмениваюсь JPG. Ура, ура всепобеждающиму бинарному представлению????

Тычеблин wrote:
> C>Покажи альтернативу.
> а без показа альтернативы очевидность сказанного сомнительна?
Да.

> не очевидно что бинарные данные прекрассно сериализуются, и передаются?
Нет. Почитай про зоопарк floating point-форматов, например. Про разные
byte-order'ы ты и сам знаешь, наверное.

> и что промежуточное преобразование в текстовый формат это исключительно
> плата за дурость и невозможность договоритья?
XML используется далеко не только для передачи данных. А еще и для их
редактирования и преобразования.

> C>Вот сейчас редактирую mapping'и Hibernate'а, они в XML. Так мне IDEA
> C>подсказывает имена тэгов, на лету валидирует ошибки и дает autocomplete
> C>по DTD.
> это такая особая магия проистекающая из сути XML?
> или это банальный инструмент который в частном случае работет с этим
> форматом.
Ну так покажи любой другой инструмент с такими же возможностями. Какие
проблемы-то?

> C>Или еще пример — я использую XSLT для преобразования POM-файлов из
> C>Maven2 в проекты IDEA.
> C>Просто некоторые не понимают что позволяют технологии, сделанные на
> базе XML.
> Просто некоторые непонимают, что бывают технологии, а бывают инструменты
> для работы с технологиями.
Так вот, технология XML позволяет легко делать такие инструменты.
Поэтому они и есть.

А вот ASN.1, который куда более гибкий, позволяющий передавать сжатые
бинарные данные, имеющий XML своим subset'ом и вообще весь такой
суперкрутой — сейчас используется по большей части в телекоме
(традиционно) и в некоторых нишевых областях. А все из-за того, что
инструменты для ASN.1 очень сложны и стоят $$$$$.

> А я например каждый день использую файловую систему по сути бинарное
> хранилище, создаю, удаляю открываю, закрываю файлы и пересылаю их по сети.
И что из этого? Ты можешь открыть "файловую систему" в своем редакторе и
сделать глобальный search/replace для времени создания файла?

> слушаю mp3, смотрю AVI, MPG, обмениваюсь JPG. Ура, ура всепобеждающиму
> бинарному представлению????
Попробуй поредактировать тэги mp3 из Notepad'а или поменять размер JPG
из FAR'а.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

C>Тычеблин wrote:
>> C>Покажи альтернативу.
>> а без показа альтернативы очевидность сказанного сомнительна?
C>Да.

ну нету её... и она непоявится до тех пор пока XML ную попсу суют во дыры.

C>Нет. Почитай про зоопарк floating point-форматов, например. Про разные
C>byte-order'ы ты и сам знаешь, наверное.

Ы? выбрать один из — это нечеловеческие усилия?

C>Ну так покажи любой другой инструмент с такими же возможностями. Какие
C>проблемы-то?

C>Так вот, технология XML позволяет легко делать такие инструменты.
C>Поэтому они и есть.

какая дичь!! в чем легкость? преобразование четырей байт в int сложнее перобразования из текстового формата?

C>Попробуй поредактировать тэги mp3 из Notepad'а или поменять размер JPG
C>из FAR'а.

а почему бы тебе на попробовать отредактировать XML с помощью стамески и молотка? или все же для разумнее подбирать подходящий инструмент.

Тычеблин wrote:
>> > C>Покажи альтернативу.
>> > а без показа альтернативы очевидность сказанного сомнительна?
> C>Да.
> ну нету её... и она непоявится до тех пор пока XML ную попсу суют во дыры.
Ну вот и предложи альтернативу.

Пока XML остается единственным общепринятым форматом для обмена
информацией. И вобщем-то, справляется с этой ролью вполне нормально.

> C>Нет. Почитай про зоопарк floating point-форматов, например. Про разные
> C>byte-order'ы ты и сам знаешь, наверное.
> Ы? выбрать один из — это нечеловеческие усилия?
Ок, я выбираю формат double'ов двойной длины (80 бит).

Как? Они не поддерживаются MSVC? Ну что же...

> C>Ну так покажи любой другой инструмент с такими же возможностями. Какие
> C>проблемы-то?
> C>Так вот, технология XML позволяет легко делать такие инструменты.
> C>Поэтому они и есть.
> какая дичь!! в чем легкость?
XML — это ТЕКСТ. А значит, ты можешь с ним использовать все стандартные
инструменты работы с текстом: поиск/замену, grep, регэкспы и т.п.

И я не касаюсь XML-специфичных вещей типа XPath.

> преобразование четырей байт в int сложнее перобразования из текстового
> формата?
Да, сложнее. Ну-ка, напиши мне преобразование из 80-битного double'а в
64-битный.

> C>Попробуй поредактировать тэги mp3 из Notepad'а или поменять размер JPG
> C>из FAR'а.
> а почему бы тебе на попробовать отредактировать XML с помощью стамески и
> молотка? или все же для разумнее подбирать подходящий инструмент.
А вот XML я могу и в FAR'е поправить. Поэтому XML и используется.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

C>Ну вот и предложи альтернативу.
я ж уже говорил что не готов. как впрочим не готов спеть лучше чем дэцел...но это не отнимает мое право назвать творчество дэцела отстоем.

C>Пока XML остается единственным общепринятым форматом для обмена
C>информацией. И вобщем-то, справляется с этой ролью вполне нормально.

были времена и лошади неплохо справлялись....пока автомобили не появились

>> C>Нет. Почитай про зоопарк floating point-форматов, например. Про разные
>> C>byte-order'ы ты и сам знаешь, наверное.
>> Ы? выбрать один из — это нечеловеческие усилия?
C>Ок, я выбираю формат double'ов двойной длины (80 бит).

C>Как? Они не поддерживаются MSVC? Ну что же...

ну допустим неподдерживает. Ы? XML способна решить эту проблемму? как? поподробнее, интересно жи....

C>XML — это ТЕКСТ. А значит, ты можешь с ним использовать все стандартные
C>инструменты работы с текстом: поиск/замену, grep, регэкспы и т.п.

цифровое изображение, музыка, видео — БИНАРНЫ А значит, ты НЕ можешь с ним использовать все стандартные инструменты работы с текстом: поиск/замену, grep, регэкспы и т.п.

или твой мир ограничен исключительно текстом?

>> преобразование четырей байт в int сложнее перобразования из текстового
>> формата?
C>Да, сложнее. Ну-ка, напиши мне преобразование из 80-битного double'а в
C>64-битный.

чем XML — то может помочь?

C>А вот XML я могу и в FAR'е поправить. Поэтому XML и используется.

а мужики то и незнают....

Тычеблин wrote:
> C>Ну вот и предложи альтернативу.
> я ж уже говорил что не готов. как впрочим не готов спеть лучше чем
> дэцел...но это не отнимает мое право назвать творчество дэцела отстоем.
Тебе необязательно самому петь лучше Дэцла — достаточно просто показать
певца, который поет лучше.

> C>Пока XML остается единственным общепринятым форматом для обмена
> C>информацией. И вобщем-то, справляется с этой ролью вполне нормально.
> были времена и лошади неплохо справлялись....пока автомобили не появились
Ну так покажи автомобиль.

> C>Ок, я выбираю формат double'ов двойной длины (80 бит).
> C>Как? Они не поддерживаются MSVC? Ну что же...
> ну допустим неподдерживает. Ы? XML способна решить эту проблемму? как?
> поподробнее, интересно жи....
Представляем дробные числа как "1.232375463487e-10" и парсим с нужной
степенью точности. Это намного веселее, чем заниматься борьбой с
endiannes и платформенными представлениями чисел.

> C>XML — это ТЕКСТ. А значит, ты можешь с ним использовать все стандартные
> C>инструменты работы с текстом: поиск/замену, grep, регэкспы и т.п.
> цифровое изображение, музыка, видео — БИНАРНЫ А значит, ты НЕ можешь с
> ним использовать все стандартные инструменты работы с текстом:
> поиск/замену, grep, регэкспы и т.п.
Именно. Поэтому с изображениями, музыкой и видео так неудобно работать.
Например, на моем компьютере сейчас нет ни одной программы
редактирования видео.

> или твой мир ограничен исключительно текстом?
Мы сейчас обсуждаем универсальный формат передачи данных.

Покажи мне редактирование звука через SSH на сервере в Америке.

> C>А вот XML я могу и в FAR'е поправить. Поэтому XML и используется.
> а мужики то и незнают....
Знают. Только они пользуются <favorite-text-editor-tool>.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Mamut, Вы писали:

M>ASN.1 кодируется в двоичные данные, кстати.
A XML можно сжимать

Never underestimate those behind you...

Здравствуйте, Тычеблин, Вы писали:

Т>чего такого уникального в XML?
Самое главное — наличие метаданных. Ключевое слово в XML — Xtensible, а не Markup.
Впрочем, я думаю, что он начнет умирать в ближайшее время. К сожалению, только массовое его распространение могло дать необходимую практику. Так что вскоре можно ожидать массового осознания недостатков XML и введения более эффективных стандартов. Я совершенно не в курсе, как это будет устроено — даже на уровне текстовый/бинарный, но как минимум придется избавиться от глупостей, заботливо всунутых в XML восторженными идиотами.

Из моего опыта, большинство реальных использований XML нарушает стандарт вдоль и поперек. Начиная прямо от выкидывания заголовка <?xml?>, а все остальное долго перечислять. Из этого я делаю вывод, что стандарт крайне неудачен: хорошему стандарту должно быть легче следовать, чем нарушать. А в XML стандарт мешает делать полезные вещи.

1.2.0 alpha rev. 655

Здравствуйте, Тычеблин, Вы писали:

Т>ну нету её... и она непоявится до тех пор пока XML ную попсу суют во дыры.
Нет. Альтернативы как раз не появится как минимум до тех пор, пока XML не позасовывают во все дыры и не осознают возникший от того дискомфорт.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Тычеблин, Вы писали:

Т>>чего такого уникального в XML?
S>Самое главное — наличие метаданных.

уверен эту "уникальность" можно воплотить в гараздо более удачной форме нежели XML ный фарш из данных и метаданных.

для меня понятно, что весь этот отстой корнями уходит в UNIX....
SMTP, FTP и HTTP а как следствие убогости перечисленного этакие костылики из BASE64....это просто наследие далекой старины когда компьютеры были такими же большими как и деревья...а почту читали в консоли

все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.

S> Я совершенно не в курсе, как это будет устроено — даже на уровне текстовый/бинарный, но как минимум придется избавиться от глупостей, заботливо всунутых в XML восторженными идиотами.

я думаю, что подобная революция под силу только компаниям уровня google или MS, а лучше в кооперации.

к сожалению в жизни, очевидно рациональные и правильные идеи даже частично воплощеные в реальность подтверждающие их правильность, Nemerle к примеру часто так и остаются на задворках...

Здравствуйте, squiz, Вы писали:

S>Здравствуйте, Mamut, Вы писали:

M>>ASN.1 кодируется в двоичные данные, кстати.
S>A XML можно сжимать

неужели

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

если у тебя 5 клиентов — это не беда.

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

... если в каждом соединении будут расжимать XML, преобразовывать в формат удобный для обработки и наоборот...

купим еще десяток серверов?

Здравствуйте, Тычеблин, Вы писали:
Т>уверен эту "уникальность" можно воплотить в гараздо более удачной форме нежели XML ный фарш из данных и метаданных.
Согласен на 100%.

Т>для меня понятно, что весь этот отстой корнями уходит в UNIX....
Т>SMTP, FTP и HTTP а как следствие убогости перечисленного этакие костылики из BASE64....
Ну, кстати ты зря. SMTP, FTP и HTTP — очень удачные протоколы. Лично я никаких особенных претензий к ним не имею. Ну разве что FTP мог бы быть немножечко постандартнее, а то все же не хватает его возможностей для современного file transfer — ни тебе компресии, ни пересылки diffgramm...
Т>это просто наследие далекой старины когда компьютеры были такими же большими как и деревья...а почту читали в консоли
Base64, кстати, тоже не вполне позорный енкодинг. Свою задачу он, собсно, выполняет. Что, в общем, не отменяет того факта, что он все же суть дощечка через заботливо вырытую собственноручно канаву: сначала мы отказываемся от передачи бинарного контента, а потом возвращаем его в заенкоженном виде.
Т>все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.
Вот кстати не надо про ICQ. Убил бы! У них там версий этого бинарного протокола — как вшей на собаке, и найти двух клиентов, способных общаться кириллицей, просто нереально. Поверь мне — уж лучше бы аська гоняла XML-based датаграммы. У меня друзья занимались написанием аськового клиента еще лет пять назад, и уже тогда матерились сверх всякой меры, а с тех пор всё только ухудшилось. Так что это — хреновый пример. Но это непринципиально, и недостатков XML не отменяет

S>> Я совершенно не в курсе, как это будет устроено — даже на уровне текстовый/бинарный, но как минимум придется избавиться от глупостей, заботливо всунутых в XML восторженными идиотами.

Т>я думаю, что подобная революция под силу только компаниям уровня google или MS, а лучше в кооперации.
Ну, само по себе изобретение больших финансов не требует. Как раз наоборот — если спека требует миллион долларов и двести человек для подготовки, результат почти 100% будет отвратительным. Просто потому, что все эти дармоеды будут честно отрабатывать деньги. Жизнеспособная спека должна быть настолько компактной, чтобы разработчик мог ее прочесть и усвоить за вечер. Остальное — по мере необходимости. Стало быть, и придумать такую спеку тоже может один человек, пусть и не за один вечер. Вот, к примеру, крайне эффективные и красивые UTF-* енкодинги были изобретены прямо в кафе на салфетке.
А вот продвинуть в массы, конечно же, должен какой-то гигант. Как только MS или Google, или хотя бы сантехники с межбизнесмашем сделают какой-то протокол основным, остальные просто вынуждены будут им следовать.

1.2.0 alpha rev. 655

Тычеблин wrote:
> если у тебя 5 клиентов — это не беда.
> Если же речь идет о системе массового обслуживания, то уже начинают
> учитывать такой показатель, как объем памяти на одно соединение..
Несерьезно, gzip/gunzip для сжатия XML на внешних интерфейсах занимают
столько времени, что о нем просто говорить смешно.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Sinclair, Вы писали:

S>Ну, кстати ты зря. SMTP, FTP и HTTP — очень удачные протоколы.

удачные протоколы в костылях не нуждаются.

S>Вот кстати не надо про ICQ. Убил бы! У них там версий этого бинарного протокола — как вшей на собаке

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

Т>>я думаю, что подобная революция под силу только компаниям уровня google или MS, а лучше в кооперации.
S>А вот продвинуть в массы, конечно же, должен какой-то гигант.

я именно этот аспект и имел ввиду

Здравствуйте, Cyberax, Вы писали:

>> учитывать такой показатель, как объем памяти на одно соединение..
C>Несерьезно, gzip/gunzip для сжатия XML на внешних интерфейсах занимают
C>столько времени, что о нем просто говорить смешно.

....мы про насосы, а нам про колесы

харе запускать дурочку....

Здравствуйте, Тычеблин, Вы писали:

Т>все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.

XMPP?

Тычеблин wrote:
> S>Ну, кстати ты зря. SMTP, FTP и HTTP — /очень/ удачные протоколы.
> удачные протоколы в костылях не нуждаются.
Напиши простого клиента, делающего запрос к SOCKS-прокси (бинарный
протокол!).

> S>Вот кстати не надо про ICQ. Убил бы! У них там версий этого бинарного
> протокола — как вшей на собаке
> верно, версий много, но это не проблемма. информации о протоколах нет, а
> вот это уже проблемма.
Вот как раз много версий — это проблема.

Ты, видимо, никогда не отлаживал программы с бинарными протоколами.
Когда днями приходится искать почему сообщения не проходят — и
оказывается, что в checksum считается один лишний байт.

Posted via RSDN NNTP Server 2.1 beta

Тычеблин wrote:
>> > учитывать такой показатель, как * объем памяти* на одно соединение..
> C>Несерьезно, gzip/gunzip для сжатия XML на внешних интерфейсах занимают
> C>*столько времени*, что о нем просто говорить смешно.
> ....мы про насосы, а нам про колесы
> харе запускать дурочку....
Объем памяти? Оверхед от gzip — примерно 64 килобайта на соединение.
Можно и меньше — будет меньше степень сжатия.

Вообще, советую поработать в реальных проектах с custom'ными бинарными и
текстовыми протоколами. Тогда, может, поймешь разницу.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Тычеблин, Вы писали:

Т>>все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.

К>XMPP?

Jabber — больше ничего на ум не приходит, ну так это просто микроб в ставнении...

Здравствуйте, Тычеблин, Вы писали:

Т>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Тычеблин, Вы писали:

Т>>>все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.

К>>XMPP?

Т>Jabber — больше ничего на ум не приходит, ну так это просто микроб в ставнении...

Ну так-то да, только вот лично Google Talk пользую и очень даже доволен (иногда аська глючит, перехожу на него)

Здравствуйте, Cyberax, Вы писали:

C>Объем памяти? Оверхед от gzip — примерно 64 килобайта на соединение.
C>Можно и меньше — будет меньше степень сжатия.

ты и в правду непонимаешь?????

повторяю, прекращай валять дурочку, читай внимательно то, о чем пишут

цитирую себя

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

если у тебя 5 клиентов — это не беда.

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

... если в каждом соединении будут расжимать XML, преобразовывать в формат удобный для обработки и наоборот...

купим еще десяток серверов?

расжимать-то в каждом соединениее полученный XML куда будем?

C>Вообще, советую поработать в реальных проектах с custom'ными бинарными и
C>текстовыми протоколами. Тогда, может, поймешь разницу.

советую не советовать, у меня свой, реально работающий под нагрузкой, application server (.NET) со своим бинарным протоколом.
я знаю о чем говорю.

Здравствуйте, Cyberax, Вы писали:

C>Вот как раз много версий — это проблема.

какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...

C>Ты, видимо, никогда не отлаживал программы с бинарными протоколами.

хочешь чтобы я это комментировал?

C>Когда днями приходится искать почему сообщения не проходят — и
C>оказывается, что в checksum считается один лишний байт.

это если ты бармэном работаешь, тогда да, большой разницы между 401 каплей или 402 нет.

в IT, даже один бит имеет значение.... вне зависимости XML это или нет.

Здравствуйте, Тычеблин, Вы писали:

Т>расжимать-то в каждом соединениее полученный XML куда будем?
Подавать на вход десериализатору, построенному на SAX-парсере. Это если надо. Так что выключай дурочку.

1.2.0 alpha rev. 655

Здравствуйте, Тычеблин, Вы писали:
Т>какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...
Ну объясни мне тогда, почему между Триллианом и ICQ кириллица в одну сторону ходит, а в другую — нет? Почему наш аськовый сервер в homenet не пускает моего кошерного 5.1 клиента?
Там это согласование протоколов сделано через дупу. Еще раз повторяю: аськовый протокол — очень плохой пример. Начиная от версионной несовместимости, которая до сих пор не решена, и заканчивая обилием критических уязвимостей, кои в частности и привели к внедрению многих из версий. Лучше бы ты привел какой-нибудь TDS.
Т>в IT, даже один бит имеет значение.... вне зависимости XML это или нет.
В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты".
Хотя, должен признать, во многом это теория. Вон на PHP SOAP реализовать — страшный геморрой. Периодически он начинает гнать на самый невинный вроде XML. Типа алиас неймспейса по-другому обзываем — и все, приехали. В итоге никто не пишет вызовы "по спецификации", а просто копируют заведомо рабочие примеры, и с осторожностью сапера меняют параметры.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Тычеблин, Вы писали:

Т>>расжимать-то в каждом соединениее полученный XML куда будем?
S>Подавать на вход десериализатору, построенному на SAX-парсере. Это если надо. Так что выключай дурочку.

а расжатый XML и SAX-парсер хранить где будем?
как сферического коня — в вакууме?

Здравствуйте, Тычеблин, Вы писали:
Т>а расжатый XML и SAX-парсер хранить где будем?
Гм. Ты как бы в курсе, что такое SAX-парсер? Я говорю о потоковой десериализации, которой не нужно держать в памяти весь XML.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Ну объясни мне тогда...

какое отношение криво написанный софт имеет к достоинствам или недостаткам бинарного/небинарного протокола? или на XML невозможно написать кривого софта?

S> Лучше бы ты привел какой-нибудь TDS.

откуда ж я знал, что у твох приятелей руки до TDS еще не дошли

Т>>в IT, даже один бит имеет значение.... вне зависимости XML это или нет.
S>В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты".

какие средства? какой диагностики? у TCP/IP этих средств выше крыши?

лично мне хватает или
хочешь сказать, что с уровня TCP/IP можно получить битую информацию?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Тычеблин, Вы писали:
Т>>а расжатый XML и SAX-парсер хранить где будем?

S>Гм. Ты как бы в курсе, что такое SAX-парсер? Я говорю о потоковой десериализации, которой не нужно держать в памяти весь XML.

1)обрати внимание на выделенное, где ты видишь весь
2)буфер нужен ?
3)при всех прочих равных утверждаю, при бинарном исполнении это все работает намного эффективнее.

Здравствуйте, Тычеблин, Вы писали:

Т>Здравствуйте, Sinclair, Вы писали:

S>>Ну объясни мне тогда...
Т>

какое отношение криво написанный софт имеет к достоинствам или недостаткам бинарного/небинарного протокола?
Гм. И в третий раз пошел он за елкой... Повторяю: Протокол ICQ — плохой пример бинарного протокола. Он демонстрирует ровно все недостатки бинарности. Поэтому не надо его использовать для критики XML. Придумай другой пример.

Т>откуда ж я знал, что у твох приятелей руки до TDS еще не дошли

Дело не в том, что дошли или не дошли. Существует более одной независимой реализации TDS; несмотря на многолетнюю историю использования, сам протокол существенно не изменился; за все время ровно в одной реализации была обнаружена ровно одна уязвимость. Я опять же могу насчет него сильно заблуждаться, т.к. внутрь его никогда не лез и вообще полагал его проприетарным, пока не услышал про независимые реализации.
Т>>>в IT, даже один бит имеет значение.... вне зависимости XML это или нет.
S>>В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты".
Т>какие средства? какой диагностики?
Выключи дурочку. Элементарная опечатка в теге будет обнаружена еще на этапе разбора, и вместо undefined behavior ты получишь вменяемое исключение от парсера.
Т>у TCP/IP этих средств выше крыши?
У TCP/IP вообще никаких средств нету. Напомню, что сам протокол не страхует тебя даже от NUXI problem. В то время, как в XML запротоколирована поддержка BOM, обеспечивающая корректное согласование неоднобайтовых енкодингов.

Т>лично мне хватает или
Т>хочешь сказать, что с уровня TCP/IP можно получить битую информацию?
Конечно можно. TCP/IP не предоставляет никаких методов контроля семантических ошибок. Мусор на входе — мусор на выходе. В XML встроены средства контроля как синтаксической корректности, так и семантической (хоть и ограниченной). В итоге очень небольшой процент ошибок добирается до собственно прикладного уровня. И их уже не так трудно отловить. А бинарные данные очень просто испортить, если изобретенный протокол не содержит специальных средств контроля. Взял ты, к примеру, и в сервере заменил двухбайтовое поле на четырехбайтовое. А клиент не знал и отправил два байта. В итоге имеем реинтерпретацию данных и хорошо, если это не приведет к переполнению буфера.
Сделать удачный бинарный протокол не так уж и просто.
С удачными текстовыми я близко знаком. К примеру, HTTP 1.1 — очень хороший протокол. Его до сих пор не на все 100% используют. Особенно удачных XML протоколов я не знаю. С бинарными протоколами работал очень мало; с тем, с чем работал — опыт скорее негативный. Отладка была сущим кошмаром, но это не показатель — опыта у меня тогда было в 10 раз меньше, чем сейчас, да и протоколы были построены поверх RS232, а не TCP/IP.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Тычеблин, Вы писали:

Т>>Здравствуйте, Sinclair, Вы писали:

S>Гм. Он демонстрирует ровно все недостатки бинарности.

ничего кроме криворукости конкретных разработчиков он не демонстрирует. и то не понятно конкретно каких. тех кто создавали протокол или тех кто пытались подражать.

Т>>откуда ж я знал, что у твох приятелей руки до TDS еще не дошли

S>Дело не в том, что дошли или не дошли. Существует более одной независимой реализации TDS; несмотря на многолетнюю историю использования, сам протокол существенно не изменился; за все время ровно в одной реализации была обнаружена ровно одна уязвимость.

именно подобными вещами я однажды и занимался, черпая информацию из декомпилированного MS JDBC драйвера. и то это была очень экзотическая ситуация когда понадобилось мультиплатформенность и эффективность.возможно есть отчаяные парни выставляющие SQL в интернет, только зачем? совсем другое дело ICQ.

Т>>лично мне хватает или
Т>>хочешь сказать, что с уровня TCP/IP можно получить битую информацию?
S>Конечно можно. TCP/IP не предоставляет никаких методов контроля семантических ошибок.

отлаженный, сериализующий софт таких ошибок не допускает.
а вот когда в фаре начинают править — сколько угодно. нефиг

S>....примеру, и в сервере заменил двухбайтовое поле на четырехбайтовое.А клиент не знал и отправил два байта. В итоге имеем

предлагаешь обсудить как кто-то сделал что-то криво?

S> С бинарными протоколами работал очень мало; с тем, с чем работал — опыт скорее негативный. Отладка была сущим кошмаром, но это не показатель — опыта у меня тогда было в 10 раз меньше, чем сейчас, да и протоколы были построены поверх RS232, а не TCP/IP.

у меня другая эволюция...
долго цеплялся за все готовое в надежде — ну не дураки ведь писали.
пока однажды не написал свой лисапет.

Здравствуйте, Тычеблин, Вы писали:

Т>1)обрати внимание на выделенное, где ты видишь весь
Т>2)буфер нужен ?
Гм. Размер буфера при этом столь невелик, что им можно пренебречь. Принципиально то, что это O(1) буфер, и потребление памяти не зависит от размера данных.
Т>3)при всех прочих равных утверждаю, при бинарном исполнении это все работает намного эффективнее.
Эффективнее — да. Насчет "всё" — не уверен. В XML реализовано очень много "всего". Не факт, что все из этого нужно. Не факт, что нужное нельзя заменить чем-то другим. Эффективность — не самая главная проблема в XML, поверь мне.

1.2.0 alpha rev. 655

Здравствуйте, Тычеблин, Вы писали:

Т>ничего кроме криворукости конкретных разработчиков он не демонстрирует.
Включи дурочку. Это утверждение нужно еще доказывать. В стотридцатьпервый раз повторяю: не надо привлекать ICQ как пример торжества бинарного протокола. Ну не работает он! Бери позитивные примеры.

Т>именно подобными вещами я однажды и занимался, черпая информацию из декомпилированного MS JDBC драйвера. и то это была очень экзотическая ситуация когда понадобилось мультиплатформенность и эффективность.возможно есть отчаяные парни выставляющие SQL в интернет, только зачем?
При чем здесь выставление в интернет? TDS, вроде как, используется и в интранете.

Т>отлаженный, сериализующий софт таких ошибок не допускает.
Выключи дурочку. Гарантии целостности желательно реализовать на уровне протокола. Напомнить тебе, что IP содержит свой чексум, хотя вроде бы Ethernet фреймы имеют свой? Вроде бы отлаженный стек TCP/IP не должен получать битых фреймов, так?
Т>предлагаешь обсудить как кто-то сделал что-то криво?
Конечно предлагаю. Интернет — это такое место, где все делают все криво. И вот HTTP, к примеру, к этому устойчив. И XML к этому устойчив.
Далее, не обязательно, чтобы это была непременно ошибка. Просто сменили версию протокола, и не все об этом вовремя узнали. На одном конце софт одной версии, на другом еще не успели перекомпилять.
Крайне желательно, чтобы такие ошибки были гарантированно детектированы, а не приводили к undefined behavior.
Например, валдиный XML оборудован схемой. И если отправитель сменил в нем схему, я это сразу замечу. А если он нарушил схему, то он даже и отправить-то документ по валидирующему каналу не сможет. Такой вот принудительный механизм соблюдения договоренностей. А ты в своем бинарном протоколе как utf-16 сериализуешь, расскажи? Нет риска нарваться на разный byte order? А floating point ты по какому стандарту передаешь? А даты как енкодятся? А часовой пояс при этом передается, или они обязаны быть в GMT? Как предполагается расширять формат? А как передаются фрагменты переменной длины — длина вначале или маркер конца?

Т>у меня другая эволюция...
Т>долго цеплялся за все готовое в надежде — ну не дураки ведь писали.
Т>пока однажды не написал свой лисапет.
Ну можешь свой лисапет на общий суд выставить. Правда, я подозреваю, что он не выдержит критики как общее решение. И даже в частном случае запросто могут найти в нем косяки, на которые ты не наступил просто в силу везения

1.2.0 alpha rev. 655

Здравствуйте, Тычеблин, Вы писали:

Т>1)обрати внимание на выделенное, где ты видишь весь

Зачем весь? Это же поток.

Т>2)буфер нужен ?

Буфер для gzip не нужен, насколько я знаю. Буфер нужен для bzip2. И то он там фреймами идет.

... << RSDN@Home 1.2.0 alpha rev. 669>>

Тычеблин wrote:
> расжимать-то в каждом соединениее полученный XML куда будем?
В память. С чего ты взял, что распарсеный бинарный протокол займет
меньше места?

Короче, несерьезно это. У нас сервер сообщений, использующий ASN.1 с PER
занимает столько же памяти, сколько и он же переписаный на XML. Нагрузка
примерно 1000 сообщений в секунду с датчиков телеметрии.

> C>Вообще, советую поработать в реальных проектах с custom'ными бинарными и
> C>текстовыми протоколами. Тогда, может, поймешь разницу.
> советую не советовать, у меня свой, реально работающий под нагрузкой,
> application server (.NET) со своим бинарным протоколом.
> я знаю о чем говорю.
Ну а я писал драйвера для железок, для которых у меня была только
спецификация протокола. Больше не хочу.

А вот с железками, которые общаются в XML работать вообще просто сказка.
Можно писать для них драйверы, просто смотря на wire protocol.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Sinclair, Вы писали:

S>Например, валдиный XML оборудован схемой. И если отправитель сменил в нем схему, я это сразу замечу. А если он нарушил схему, то он даже и отправить-то документ по валидирующему каналу не сможет.

Это при условии, что отправитель не поменял содержимое самой схемы.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это при условии, что отправитель не поменял содержимое самой схемы.
Ну, по идее, обе стороны используют одну и ту же схему.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

ГВ>>Это при условии, что отправитель не поменял содержимое самой схемы.
S>Ну, по идее, обе стороны используют одну и ту же схему.

Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.
Либо реализовать версионность протокола обмена — либо проблемы клиентов.

Имхо так.

Геннадий Васильев wrote:
> Я неудачно сформулировал. Вопрос должен быть таким: что делать, если
> софт у получателя остался прежним, а схема валидации XML поменялась?
> Прилетает совершенно валидное XML-сообщение, к которому не готов софт
> получателя.
В таком случае мы, хотя бы, сразу можем диагностировать ошибку. А вот с
бинарным протоколом может быть что угодно.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась?
А-а, это я неудачно ответил. На самом деле софт, если он построен в расчете на какую-то схему, должен тащить ее с собой. И валидировать документ именно ею. А иначе — да, всё верно, формальная валидация даст не больше пользы, чем IP Checksum.

1.2.0 alpha rev. 655

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Sinclair, Вы писали:

ГВ>>>Это при условии, что отправитель не поменял содержимое самой схемы.
S>>Ну, по идее, обе стороны используют одну и ту же схему.

ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.

А что будет в бинарном?

Здравствуйте, Cyberax, Вы писали:

>> Прилетает совершенно валидное XML-сообщение, к которому не готов софт
>> получателя.
C>В таком случае мы, хотя бы, сразу можем диагностировать ошибку.

Это зависит от многих факторов. Например, если добавлены новые узлы, то условно "старый" софт их просто проигнорирует, не заморачиваясь диагностикой.

C>А вот с бинарным протоколом может быть что угодно.

Бинарные протоколы тоже бывают разные, не стоит обобщать.

Здравствуйте, Sinclair, Вы писали:

S>А-а, это я неудачно ответил. На самом деле софт, если он построен в расчете на какую-то схему, должен тащить ее с собой. И валидировать документ именно ею.

Да, я именно это и имел ввиду. То есть общая проблема согласования версий сообщений остаётся. И в этом смысле совершенно не важно, как именно мы доказываем допустимость обработки конкретного сообщения: посредством схемы или простым сравнением 4-х байт в начале бинарного пакета.

S>А иначе — да, всё верно, формальная валидация даст не больше пользы, чем IP Checksum.

Именно. Она только поможет доказать, что сообщение не покорёжено и соответствует какой-то схеме.

Здравствуйте, aka50, Вы писали:

ГВ>>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.

A>А что будет в бинарном?

В каком именно?

Геннадий Васильев wrote:
> C>В таком случае мы, хотя бы, сразу можем диагностировать ошибку.
> Это зависит от многих факторов. Например, если добавлены новые узлы, то
> условно "старый" софт их просто проигнорирует, не заморачиваясь
> диагностикой.
Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой валидации.

> C>А вот с бинарным протоколом может быть что угодно.
> Бинарные протоколы тоже бывают разные, не стоит обобщать.
Ну так сложные бинарные протоколы обычно не проще XML.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

>> C>В таком случае мы, хотя бы, сразу можем диагностировать ошибку.
>> Это зависит от многих факторов. Например, если добавлены новые узлы, то
>> условно "старый" софт их просто проигнорирует, не заморачиваясь
>> диагностикой.
C>Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой валидации.

Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.

>> C>А вот с бинарным протоколом может быть что угодно.
>> Бинарные протоколы тоже бывают разные, не стоит обобщать.
C>Ну так сложные бинарные протоколы обычно не проще XML.

Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов, они бывают — разные.

Здравствуйте, Cyberax, Вы писали:

C>Ну а я писал драйвера для железок, для которых у меня была только
C>спецификация протокола. Больше не хочу.

C>А вот с железками, которые общаются в XML работать вообще просто сказка.
C>Можно писать для них драйверы, просто смотря на wire protocol.

Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты посмотрел wire protocol, запрограммровал один раз драйвер для него и — всё. А железка продолжает гонять по сети эту уже никому не нужную документацию.

Геннадий Васильев wrote:
> C>А вот с железками, которые общаются в XML работать вообще просто сказка.
> C>Можно писать для них драйверы, просто смотря на wire protocol.
> Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты
> посмотрел wire protocol, запрограммровал один раз драйвер для него и —
> всё. А железка продолжает гонять по сети эту уже никому не нужную
> документацию.
Так пусть себе гоняет — даже 1000 устройств не загружает 10Mbit-сеть. В
новых версиях XML еще может сжиматься gzip'ом — так там вообще траффик
копеечный.

Кроме того, пригодность для быстрого анализа и нахождения проблем — это
огромный плюс, превышающий копеечную экономию на сети.

Posted via RSDN NNTP Server 2.1 beta

Геннадий Васильев wrote:
> C>Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой
> валидации.
> Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.
Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте

Так как в этом случае софт будет зависеть от [ненадежного] внешнего
соединения.

>> > C>А вот с бинарным протоколом может быть что угодно.
>> > Бинарные протоколы тоже бывают разные, не стоит обобщать.
> C>Ну так сложные бинарные протоколы обычно не проще XML.
> Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов,
> они бывают — /разные/.
Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
подробной документации на досуге написать парсер ASN.1 PER — занятие еще то.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

>> Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.
C>Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте

C>Так как в этом случае софт будет зависеть от [ненадежного] внешнего
C>соединения.

Угу. А я ни разу не видел, чтобы бинарные протоколы не сопровождались средствами контроля версий и целостности данных.

>>> > C>А вот с бинарным протоколом может быть что угодно.
>>> > Бинарные протоколы тоже бывают разные, не стоит обобщать.
>> C>Ну так сложные бинарные протоколы обычно не проще XML.
>> Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов,
>> они бывают — /разные/.
C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
C>подробной документации на досуге написать парсер ASN.1 PER — занятие еще то.

Что за глупость? Писать парсер без подробной документации по исходным данным?

Здравствуйте, Cyberax, Вы писали:

>> Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты
>> посмотрел wire protocol, запрограммровал один раз драйвер для него и —
>> всё. А железка продолжает гонять по сети эту уже никому не нужную
>> документацию.
C>Так пусть себе гоняет — даже 1000 устройств не загружает 10Mbit-сеть. В
C>новых версиях XML еще может сжиматься gzip'ом — так там вообще траффик
C>копеечный.

C>Кроме того, пригодность для быстрого анализа и нахождения проблем — это
C>огромный плюс, превышающий копеечную экономию на сети.

Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.

Геннадий Васильев wrote:
> C>Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте
> C>Так как в этом случае софт будет зависеть от [ненадежного] внешнего
> C>соединения.
> Угу. А я ни разу не видел, чтобы бинарные протоколы не сопровождались
> средствами контроля версий и целостности данных.
Показать?

> C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
> C>подробной документации на досуге написать парсер ASN.1 PER — занятие
> еще то.
> Что за глупость? Писать парсер без подробной документации по исходным
> данным?
Неудачно выразился — попробуй написать парсер только по спеке, без примеров.

Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
все. А потом подумай — почему оно почти никому не нужно.

Posted via RSDN NNTP Server 2.1 beta

Геннадий Васильев wrote:
> C>Кроме того, пригодность для быстрого анализа и нахождения проблем — это
> C>огромный плюс, превышающий копеечную экономию на сети.
> Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.
Так я и говорю — в большинстве случаев это непринципиально.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Андрей Коростелев, Вы писали:

На всякий случай напомню коллегам, углубившимся в ветку: я не думаю, что основная проблема XML — эффективность. Проблема, как я вижу, в том, что он неудобен для решения именно тех задач, для которых предназначался. Он очень сложный, непонятный, и выполнение большинства требований стандарта сулит только геморрой, а не удобство.
Ну вот, к примеру: нельзя трактовать подветку XML как самостоятельный документ. А очень часто требуется именно это: построение композитных документов, где часть мало знает о целом, а целое — о частях. И что? Народ выкручивается: вытаскивает outerXml и приклеивает к нему заголовок. Бред? Бред. Либо хитрит с парсерами, нарушая стандарт.
Про ситуацию с неймспейсами я лучше умолчу, т.к. у меня недостаточно квалификации для полноценного обсуждения, да и тема недавно поднималась.

1.2.0 alpha rev. 655

Sinclair wrote:
> На всякий случай напомню коллегам, углубившимся в ветку: я не думаю, что
> основная проблема XML — эффективность. Проблема, как я вижу, в том, что
> он неудобен для решения именно тех задач, для которых предназначался. Он
> очень сложный, непонятный, и выполнение большинства требований стандарта
> сулит только геморрой, а не удобство.
Так фича в том, что в XML, большей частью, используют только
подмножество стандарта. Примерно как в С++.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

C>Ты, видимо, никогда не отлаживал программы с бинарными протоколами.
C>Когда днями приходится искать почему сообщения не проходят — и
C>оказывается, что в checksum считается один лишний байт.
А как им славно сносит крышу, если промахнуться хотя бы на один байт !

На самом деле, основной гемор даже не этот (по моему опыту), а то, что чаще всего их реализовывают в виде чего-нибудь типа

struct PROTOCOL_HEADER { ...  };
PROTOCOL_HEADER hdr;
fread(&hdr, 1, sizeof(hdr), file);

а потом начинаются пляски с выравниванием, byte order'ом и так далее.

Альтернатива -- писать байтовый поток в платформонезависимом виде, а потом долго-долго ручками выписывать stream_read_dword() / convert_network_to_host_dword() и так далее.

Честно говоря, я так и не решил для себя что лучше.

ps. Заюзать что-то типа rpcgen можно, но не всегда, к сожалению.

Здравствуйте, Cyberax, Вы писали:
C>Так фича в том, что в XML, большей частью, используют только
C>подмножество стандарта. Примерно как в С++.
Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти XML", который нельзя назвать XML с точки зрения стандарта.

1.2.0 alpha rev. 655

Здравствуйте, Cyberax, Вы писали:

>> C>огромный плюс, превышающий копеечную экономию на сети.
>> Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.
C>Так я и говорю — в большинстве случаев это непринципиально.

Но того принципа, в соответствии с которым гоняется ненужная документация, это не отменяет.

Здравствуйте, Cyberax, Вы писали:

>> Угу. А я ни разу не видел, чтобы бинарные протоколы не сопровождались
>> средствами контроля версий и целостности данных.
C>Показать?

Да ладно, поверю на слово.

>> C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
>> C>подробной документации на досуге написать парсер ASN.1 PER — занятие
>> еще то.
>> Что за глупость? Писать парсер без подробной документации по исходным
>> данным?
C>Неудачно выразился — попробуй написать парсер только по спеке, без примеров.

Час от часу...

C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
C>все. А потом подумай — почему оно почти никому не нужно.

Можем хоть новый топик открыть. Только встречный вопрос: а как это поможет опровергнуть моё высказывание о том, что "бинарные протоколы бывают разные"?

Здравствуйте, Sinclair, Вы писали:

S>Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти XML", который нельзя назвать XML с точки зрения стандарта.

Эта проблема не только XML. Последнее что я видел такого рода — это "почти HTTP", когда сессии свои придумали и аутентикацию — тоже свою, да ещё и с нарушением синтаксиса HTTP'шного. Случаются же такие вещи обычно даже не из худших побуждений, а от незнания: люди не осознают, что XML — это технология, которую используют из-за того, что к ней есть пачка инструментов для обработки; они думают, что XML — это "вот эти угловые скобочки" (молчу про XML infoset) и используется, "чтобы сделать данные читаемыми", и "улучшают" его, теряя все бенефиты XML.

Геннадий Васильев wrote:
> C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
> C>все. А потом подумай — почему оно почти никому не нужно.
> Можем хоть новый топик открыть. Только встречный вопрос: а как это
> поможет опровергнуть моё высказывание о том, что "бинарные протоколы
> бывают разные"?
Так я и не собирался. Я только говорю, что сложные бинарные протоколы —
обычно сложнее, чем аналогичные текстовые.

Posted via RSDN NNTP Server 2.1 beta

Sinclair wrote:
> C>Так фича в том, что в XML, большей частью, используют только
> C>подмножество стандарта. Примерно как в С++.
> Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются
> стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти
> XML", который нельзя назвать XML с точки зрения стандарта.
Не знаю, обычно базовый стандарт (правила квотирования, указание
DTD/Schema, один тэг верхнего уровня и т.п.) вполне соблюдается.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
C>все. А потом подумай — почему оно почти никому не нужно.
Насчет почти никому — да полно телекоммуникационных протоколов на нем построено:

The ASN.1 notation is extensively used in telecom industry (examples include cell networks' MMS (multimedia services) and telecom equipment CDR (Call Data Records), TAP3 (Transferred Account Procedure)), security protocols and data formats (PKIX/X.509) and other high-profile applications. If you are using SSL (HTTPS) to access a bank or email account, be sure the ASN.1 is involved too; it describes the structure of the server's identity certificate for verification by your Internet browser.

А распространен меньше чем XML потому что, вероятно, полностью реализовать слишком сложно и коммерческие реализации стоят дорого:

The question is: why not every programmer developing the network protocols and/or data formats is using the ASN.1? One of the answers is that the cost of commercial ASN.1 compiler is often prohibitive for small-to-medium sized projects.

(цитаты отсюда)

А также потому что он существовал уже давно и во время .com бума не стал модным buzzword в отличие от XML

А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset имеет ИМХО весьма неплохие перспективы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Андрей Хропов wrote:
> C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
> C>все. А потом подумай — почему оно почти никому не нужно.
> Насчет почти никому — да полно телекоммуникационных протоколов на нем
> построено
Ну так я, по-моему, сказал, что ASN.1 исторически используется в
телекоме. В SSL он очень рудиментарно используется, в основном для
представления сертификатов.

Недавно делал сертификат для сервера с несколькими vhost'ами. Как все
было бы проще, если бы сертификаты были в простом XML...

> А распространен меньше чем XML потому что, вероятно, полностью
> реализовать слишком сложно и коммерческие реализации стоят дорого:
Именно.

> А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset
> <http://en.wikipedia.org/wiki/Fast_Infoset> имеет ИМХО весьма неплохие
> перспективы.
Так это просто кодировка XML — то есть при работе с ней нужно почти
столько же ресурсов, сколько и с обычным XMLем. Так что у нее нет особых
преимуществ перед связкой xml+gzip.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

>> А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset
>> <http://en.wikipedia.org/wiki/Fast_Infoset> имеет ИМХО весьма неплохие
>> перспективы.
C>Так это просто кодировка XML — то есть при работе с ней нужно почти
C>столько же ресурсов, сколько и с обычным XMLем. Так что у нее нет особых
C>преимуществ перед связкой xml+gzip.
У нее есть принципиальные преимущества, потому что сжатие происходит с учетом особенностей сжимаемой информации (а не просто универсальный gzip), что всегда выгоднее как с точки зрения компактности, так и с точки зрения обработки (например, возможно представлять xsd:float действительно как IEEE754 float, а не парсить в/из текста, удобней делать поиск (для gzip придется каждый раз разжимать и сериализовывать весь распакованный файл) и т.п.)

Собственно, насчет ресурсов — см. исследование здесь.

В общем-то я вообще считаю XML плохим стандартом, поскольку он неоптимален ни для людей:

1) Слишком многословен, людям ближе специализированные средства, позволяющие более удобно/компактно выражать свои мысли (языки программирования для программирования, Word для документов и т.д.) (хорошая иллюстрация — CSAML vs С#);

2) Не является языково-нейтральным. Схема (набор тегов) определяется, как правило, на определенном естественном языке. Соответственно, людям, не понимающим данный язык, он непонятен. Это также касается и представления дат и числительных.

...
ни для компьтеров:

1) Компьютеры оперируют бинарными данными, а не текстом (текст — это только частный случай). Зачем дополнительные операции сериализации/десериализации, в частности для чисел?

Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

АХ>Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

А почему не EBML?

Здравствуйте, Sinclair, Вы писали:

S>Ну вот, к примеру: нельзя трактовать подветку XML как самостоятельный документ.

И в чем проблема? У нас вовсю в проекте такая фича используется.

S> А очень часто требуется именно это: построение композитных документов, где часть мало знает о целом, а целое — о частях.

Ага.

S> И что? Народ выкручивается: вытаскивает outerXml и приклеивает к нему заголовок. Бред? Бред.

Бред конечно.

S>Про ситуацию с неймспейсами я лучше умолчу, т.к. у меня недостаточно квалификации для полноценного обсуждения

Ну вот и ответ на вопрос, почему ваш народ не может нормально работать с композитными документами. Неймспейсы как раз для таких документов и придумывались.

... << RSDN@Home 1.2.0 alpha rev. 669 on Windows XP 5.1.2600.131072>>

M>А почему не EBML?

А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>>А почему не EBML?

L>А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

За ним стоит формат "матрешка"(matroska) для видео файлов. И больше, по-моему, никто

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Тычеблин, Вы писали:
Т>>какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...
S>Ну объясни мне тогда, почему между Триллианом и ICQ кириллица в одну сторону ходит, а в другую — нет?

Странно. У меня триллиан, у моего коллеги ICQ, общаемся без проблем. Правда, он там в настройках ICQ что-то поменял

L>>А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

M>За ним стоит формат "матрешка"(matroska) для видео файлов. И больше, по-моему, никто

Тогда связываться с ним буду разве что совсем по безнадёге

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Странно.
Ничего странного. У меня с некоторыми людьми кириллица ездит:
— в обе стороны
— только от меня
— только ко мне
— от меня вообще ничего не ездит, ни кириллица, ни латиница — пустышки приходят.

Это и есть чудеса бинарного протокола: нет нормального способа поддерживать разные версии на разных концах соединения.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Ничего странного. У меня с некоторыми людьми кириллица ездит:
S>- в обе стороны
S>- только от меня
S>- только ко мне
S>- от меня вообще ничего не ездит, ни кириллица, ни латиница — пустышки приходят.

S>Это и есть чудеса бинарного протокола: нет нормального способа поддерживать разные версии на разных концах соединения.

В триллиане другая прелесть есть. До поры до времени у меня была версия 0.x, она логи писала в 1251. Потом они ее заменили на 3.x, эта пишет логи в UTF8. Так что у меня логи теперь в начале в 1251, а в конце — UTF8.

А насчет бинарного протокола — не совсем согласен. Версии поддерживать можно, если это в структуру заложено. Читает же Word все .doc файлы — а это , по сути, то же самое. Кто им мешал в ICQ протоколе поле VERSION завести ? Даже из 4 частей можно было, как в .Net

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Альтернатива -- писать байтовый поток в платформонезависимом виде, а потом долго-долго ручками выписывать stream_read_dword() / convert_network_to_host_dword() и так далее.
А если чутка подумать? Хоть в С++ с метапрограммированием и хреново но на эту задачку его хватит.
Допилить до кондиции напильником

template<int N>
struct GenericIO
{
    template<class Stream, class Type>
    static void writeLittleEndian(Stream& stream, Type const& t)
    {
        stream.writeByte(((char*)&t)[sizeof(Type) - N]);
        GenericIO<N - 1>::writeLittleEndian(stream, t);
    }
    template<class Stream, class Type>
    static void writeBigEndian(Stream& stream, Type const& t)
    {
        stream.writeByte(((char*)&t)[N - 1]);
        GenericIO<N - 1>::writeBigEndian(stream, t);
    }

    template<class Stream, class Type>
    static void readLittleEndian(Stream& stream, Type& t)
    {
        stream.readByte(((char*)&t)[sizeof(Type) - N]);
        GenericIO<N - 1>::readLittleEndian(stream, t);
    }
    template<class Stream, class Type>
    static void readBigEndian(Stream& stream, Type& t)
    {
        stream.readByte(((char*)&t)[N - 1]);
        GenericIO<N - 1>::readBigEndian(stream, t);
    }
};

template<>
struct GenericIO<0>
{
    template<class Stream, class Type>
    static void writeLittleEndian(Stream& stream, Type const& t){}
    template<class Stream, class Type>
    static void writeBigEndian(Stream& stream, Type const& t){}
    template<class Stream, class Type>
    static void readLittleEndian(Stream& stream, Type& t){}
    template<class Stream, class Type>
    static void readBigEndian(Stream& stream, Type& t){}
};

template<class Stream>
void writeLittleEndian(Stream& stream, int i)
{
    GenericIO<sizeof(int)>::writeLittleEndian(stream, i);
}

template<class Stream>
void writeBigEndian(Stream& stream, int i)
{
    GenericIO<sizeof(int)>::writeBigEndian(stream, i);
}

template<class Stream>
void readLittleEndian(Stream& stream, int& i)
{
    GenericIO<sizeof(int)>::readLittleEndian(stream, i);
}

template<class Stream>
void readBigEndian(Stream& stream, int& i)
{
    GenericIO<sizeof(int)>::readBigEndian(stream, i);
}

struct TestWriteStream
{
    template<class T>
    TestWriteStream& operator()(T const& t)
    {
        writeBigEndian(*this, t);
        return *this;
    }

    void writeByte(char b)
    {
        std::cout << std::hex << (int)b << " ";
    }
};

struct TestReadStream
{
    template<class T>
    TestReadStream& operator()(T& t)
    {
        readBigEndian(*this, t);
        return *this;
    }

    void readByte(char& b)
    {
        int n;
        std::cin >> std::hex >> n;
        b = n;
    }
};

struct Test
{
    int i;
    int j;
};

template<class Stream>
void testStream(Stream& stream, Test& test)
{
    stream
        (test.i)
        (test.j)
        ;
}

int main()
{
    TestReadStream rs;
    TestWriteStream ws;
    Test t = {12314, 3643};
    testStream(ws, t);
    testStream(rs, t);
    testStream(ws, t);
    return 0;
}

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Mamut, Вы писали:

АХ>>Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

M>А почему не EBML?

Не знаю, а насколько он соответствует XML Binary Characterization Properties?

Сравнение тех форматов, которые им предоставили Analysis of the EXI Measurements.

Самым крутым по сжатию получается Efficient XML, который разработан компанией AgileDelta, и основан на Knowledge Based Compression (здесь). Интервью с создателем здесь. Вроде как они пока спецификацию не открыли, но пророчат ее на роль W3C стандарта (тогда типа откроем — здесь).

А на самом деле самое лучшее для обычного XML это как я выяснил (хотя у самого подобные мысли были) — XML Screamer, в общем надо замутить реализацию этого дела для Немерле, который отлично для этого подходит

.

А еще лучше объединить этот самый Screamer c каким-нибудь из бинарных стандартов XML (когда в W3C наконец примут таки его)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В триллиане другая прелесть есть. До поры до времени у меня была версия 0.x, она логи писала в 1251. Потом они ее заменили на 3.x, эта пишет логи в UTF8. Так что у меня логи теперь в начале в 1251, а в конце — UTF8.

Я это тоже пережил.

PD>А насчет бинарного протокола — не совсем согласен. Версии поддерживать можно, если это в структуру заложено. Читает же Word все .doc файлы — а это , по сути, то же самое.
О, вот еще один плохой пример. Попробуй открыть в Word 6.0 файл от Word 97 — будешь неприятно удивлен. То, что Word 2003 читает все .doc файлы — заслуга Word, а не .doc.

Насколько я знаю, в протоколе ICQ поле Version как раз есть. Нету каких-то других полей, которые позволили бы, к примеру, корректно указывать кодировку строк.
Эти проблемы, конечно, не вполне связаны с бинарностью, но они, имхо, ей усугубляются.

1.2.0 alpha rev. 655

Здравствуйте, Sinclair, Вы писали:

S>Насколько я знаю, в протоколе ICQ поле Version как раз есть. Нету каких-то других полей, которые позволили бы, к примеру, корректно указывать кодировку строк.
S>Эти проблемы, конечно, не вполне связаны с бинарностью, но они, имхо, ей усугубляются.

Ну если мы решим с тобой обмениваться текстовыми файлами на русском языке по ftp , смотреть их в FAR без плагинов, то тоже хорошего мало будет

Здравствуйте, Pavel Dvorkin, Вы писали:

Короче, заколебал меня FAR окончательно. Поискал по инету — оказывается, проблема с приемом UTF-8 под ICQ протоколом восьмой версии у них известна чуть ли не с 2002 года. Починить разработчики ее до сих пор не могут, преимущественно потому, что клинически не разбираются в предмете. К счастью, народные умельцы нашли в DLL то место, где вызывается автодетектирование кодировки. Судя по всему, эта функция вычисляет текущую кодировку винды

. Замена call на mov eax, <номер UTF-8> решает проблему. Я пропатчил себе aim.dll и теперь кириллица принимается нормально.

1.2.0 alpha rev. 655

>> не очевидно что бинарные данные прекрассно сериализуются, и передаются?
C>Нет. Почитай про зоопарк floating point-форматов, например. Про разные
C>byte-order'ы ты и сам знаешь, наверное.
ASN.1 учитывает все это.

... << RSDN@Home 1.1.4 stable rev. 510>>

Ka3a4oK wrote:
> C>Нет. Почитай про зоопарк floating point-форматов, например. Про разные
> C>byte-order'ы ты и сам знаешь, наверное.
> ASN.1 учитывает все это.
Угу. А теперь советую посмотреть на его распространение.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Тычеблин, Вы писали:

C>>Вообще, советую поработать в реальных проектах с custom'ными бинарными и
C>>текстовыми протоколами. Тогда, может, поймешь разницу.

Т>советую не советовать, у меня свой, реально работающий под нагрузкой, application server (.NET) со своим бинарным протоколом.
Т>я знаю о чем говорю.

МТС внешние платежные шлюзы — XML-протокол
Cyberplat — текстовый
e-port — XML-протокол
U-TEL — (по косвенным признакам средняя нагрузка — 50-200 платежных транзакций в секунду) — текстовый

ты будешь спорить что у них небольшой трафик и небольшая нагрузка на сервера?

... << RSDN@Home 1.2.0 alpha rev. 0>>

От:	Андрей Коростелев	http://www.korostelev.net/
Дата:	21.12.06 15:50
Оценка:	281 (12)

От:	lkurts	http://lktalks.blogspot.com
Дата:	21.12.06 15:55
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	21.12.06 15:57
Оценка:

	От:	fddima
	Дата:	21.12.06 16:04
	Оценка:

	От:	Mikl Kurkov
	Дата:	21.12.06 16:21
	Оценка:	1 (1)

От:	Нахлобуч	https://hglabhq.com
Дата:	21.12.06 16:35
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	21.12.06 16:54
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	22.12.06 05:13
Оценка:	+4

	От:	Тычеблин
	Дата:	22.12.06 07:34
	Оценка:	1 (1) +4 -3

	От:	yoriсk.kiev.ua
	Дата:	22.12.06 11:31
	Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	22.12.06 12:38
Оценка:	2 (1) +1

	От:	Cyberax
	Дата:	24.12.06 12:55
	Оценка:	1 (1) +3

	От:	Turtle.BAZON.Group
	Дата:	25.12.06 11:53
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	25.12.06 12:54
Оценка:

	От:	Eugene Kilachkoff
	Дата:	26.12.06 15:25
	Оценка:

От:	dottedmag	http://dottedmag.net/
Дата:	27.12.06 03:17
Оценка:

	От:	Андрей Хропов
	Дата:	04.01.07 18:17
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	08.01.07 12:47
Оценка: