Как направить XML в скоростной ряд?

[Sh0Ck_filE]

Технология Extensible Markup Language стала практически универсальным средством обмена информацией в онлайне. Но все чаще можно услышать признание, что за преимущества XML подчас приходится платить снижением производительности.

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

Источник: ЗДнет <- <a href='http://news.com.com/Putting+XML+in+the+fast+lane/2100-7345_3-5534249.html?tag=st.prev' target='_blank'>оригинал</a>

<span style='color: #999999'>Добавлено([mergetime]1105988345[/mergetime]):</span>

Проблема в следующем: сейчас стандарт XML предписывает хранить информацию в виде текста. Это означает, что XML-документ, такой как заказ-наряд или веб-страница, может легко воспринять человек или «считать» машина — при помощи многочисленных редакторов текста или XML-парсеров.

Но из-за тенденции XML к созданию очень крупных файлов возникают проблемы производительности. Отчасти причина в требовании, чтобы каждый элемент XML-документа помечался текстовыми метками. К тому же основанные на XML протоколы, называемые веб-сервисами, также генерируют значительный XML-трафик.

«XML не только многословен, но и чересчур избыточен с точки зрения пространства, приходящегося на единицу передаваемых полезных данных», — утверждает Джефф Лам, главный технолог компании Leader Technologies, где XML интенсивно используется для проведения телеконференций и где убеждены, что нужно что-то менять.

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

Sun Microsystems инициировала проект open source Fast Infoset Project, основанный на бинарном XML, а ответственная за XML организация по стандартизации World Wide Web Consortium (WC3) сформировала рабочую группу Binary Characterization Working Group, которая займется переводом XML в двоичный формат.

На первый взгляд, компрессия XML-документов за счет использования другого формата может показаться разумным способом решения проблемы медлительности. Но сама идея вызывает у многих — включая пионера XML в самой Sun — опасения, что в результате могут появиться несовместимые версии XML. «Будь я властителем мира, я запретил бы бинарный XML, и я совершенно уверен, что те, кто его проталкивает, могли бы найти другое решение, — говорит Тим Брэй, соавтор XML и глава софтверного отделения Sun. — Но эти люди уверены в своей правоте, и они не глупы, так что не исключено, что они действительно правы. Поэтому остается надеяться, что они будут взаимодействовать с организациями по стандартизации и выпустят это ПО в виде открытого проекта open source — именно так, надо отдать им должное, поступают люди из Sun Fast-Infoset».

Пресс для XML
План Fast Infoset, ставший результатом более чем года работы, предполагает сжатие XML-документов в двоичный формат с целью ускорения процесса передачи файлов по интернету. Sun выбрала способ компрессии, уже стандартизованный в телекоммуникационной индустрии.

Инженеры Sun, участвующие в проекте Fast Infoset, утверждают, что преобразование в двоичный код необходимо, так как оно может существенно улучшить производительность, без чего в определенных ситуациях не обойтись. В ходе первых испытаний было установлено, что с этим ПО приложения работают в два-три раза быстрее. Цель проекта Fast Infoset — вызывать заинтересованность у разработчиков и со временем создать стандартизованный бинарный формат.

К созданию бинарного XML-формата призывают и производители потребительских устройств и мобильных телефонов, такие как Canon и Nokia. Без этого крупные файлы изображений слишком долго загружаются в устройства.

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

Брэй скептически настроен по отношению к идее преобразования XML в какой бы то ни было нетекстовой формат. «На практике тот факт, что XML — это обычный простой текст, который можно прочесть в Notepad... оказался благом, — говорит он. — При всяком отклонении от этого прямого и узкого пути мы рискуем утратить совместимость. Опыт взаимодействия через XML, как он есть, дает отличные результаты. Зачем что-то менять?»

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

Жанет Перна, генеральный менеджер IBM Information Management Group, называет в качестве одной из альтернатив бинарному XML борьбу с разрастанием XML-трафика путем ускорения сетевых операций. Пять или шесть лет назад считалось, что интернет будет слишком медленным для онлайновой коммерции, но со временем технология устранила это препятствие, напомнила она. «Я не считаю (растущий XML-трафик) ограничением. Думаю, что мы с этим справимся».

Аналитическая фирма ZapThink, специализирующаяся на XML и веб-сервисах, разделяет опасения по поводу бинарного XML, особенно в части возможности проприетарных реализаций. Аналитики ZapThink отмечают также, что XML-сообщение может затрагивать несколько разных компонентов ПО и аппаратуры, таких как системы защиты, каждый из которых должен будет поддерживать любые стандарты бинарного XML.

Рон Шмельцер из ZapThink говорит, что применение бинарного XML может ограничиться рыночными нишами, такими как приложения, в которых передаются очень большие объемы данных и где требуется максимальная производительность.

Лам из Leader Technologies поддерживает идею бинарного XML, но при одном важном условии — чтобы он был стандартизованным. «Число транзакций, содержащих XML, продолжает нарастать как снежный ком, и мы не хотим оказаться в ловушке, — говорит он. — Но если мы не сможем прийти к стандарту (бинарного XML), то я перестану поддерживать эту идею».

[SiMM]

Для "танкистов" - запылившееся повествование о маляре Шлемиэле в статье "<a href='http://russian.joelonsoftware.com/Articles/BacktoBasics.html' target='_blank'>Назад, к основам</a> Джоэля Спольски (в кратце - объяснение на пальцах, почему же эта модная штучка так медлительна).

[Sh0Ck_filE]

2SiMM:
Вот поэтому я и не хочу юзать хмл в оFFлайн-клиенте <!--emo&:(-->[img]style_emoticons/<#EMO_DIR#>/sad.gif[/img]<!--endemo-->

[Scalder]

А вот, что показывает мой опыт использования технологии XML в моей последней программе.
Программа писалась на Java и мне для более простого решения задачи необходим был парсер один в одни повторяющий xml парсер в C#.
Что мной и было реализованно.
В результате мной на данный момент получен результат:
Исходный xml, размер - 1070 кб.
Упакованн в zip и полученный размер - 113 488 байт
Приблизительной время чтения и разбора xml файла - 351 мс.
И данный результат получен на не самой быстрой технологии - Java.
Я не сомневаюсь, что на нативном коде можно получить не менее чем на треть более быстрый результат.

Как это было полученно:
1) Код писался в торопях и я уверен, что есть способы зделать его быстрее и продуктивнее.
Но мне пока и так хорошо . Может когда будет время....
2) Не реализованны многочисленный проверки и некоторые сервисные функци:
а) Какова фиг парсер должен знат положение в дереве парсируемого документа? имхо - проблема программера, незачем..
б) Проверка документа происходин на стадии его чтения, т.к. в момент запроса тега, парситься только этот тэг.
в) Отошел от некоторых не совсем мне понятных ограничений xml, например:
почему в параметре тега нельзя использовать напрямую символы "<>"? и др?.
имхо - изврат.
Именно благодоря таким "дебильным" ограничениям мы и имеем тормозной xml парсер, выход - упростить формат и всё залетает.
Ведь изначально задумывался как простой и понятный, ЛОГИЧНЫЙ!!!
<!--QuoteBegin-Sh0Ck_filE+Jan 18 2005, 00:41--><div class='quotetop'>QUOTE(Sh0Ck_filE @ Jan 18 2005, 00:41)</div><div class='quotemain'><!--QuoteEBegin-->Вот поэтому я и не хочу юзать хмл в оFFлайн-клиенте sad.gif
[right][snapback]160537[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Почему говоришь?

[SiMM]

<!--QuoteBegin-Scalder+Jan 18 2005, 09:58--><div class='quotetop'>QUOTE(Scalder @ Jan 18 2005, 09:58)</div><div class='quotemain'><!--QuoteEBegin-->Именно благодоря таким "дебильным" ограничениям мы и имеем тормозной xml парсер, выход - упростить формат и всё залетает.<!--QuoteEnd--></div><!--QuoteEEnd-->Ошибаешься. Нормальные ограничения. Иначе подобное (<item></item><item></item>) вообще невозможно было бы разобрать однозначно (то ли это два item'а, то ли это содержимое item'а соответствует </item><item>). А по поводу остального - во-первых, насколько я тебя понял, ты писал парсер под индивидуальную задачу, зная структуру документа & etc. Во-вторых, объём в 1 Мб - довольно смешная цифра (попробуй озоновские списки в десятки мегабайт). В-третьих - zip тут не при делах, хотя если использовать XML по прямому назначению (импорт/экспорт данных) - то всё правильно, никто этого не запрещает. В-четвёртых, более быстрый результат по сравнению со своим ты может и получишь. Но использовать XML для крупных БД просто глупо - даже поиск по столбцу - далеко не банальная операция, в отличии от случая с классическим способом хранения данных (статью почитай, если ещё не ознакомился). Ну а в пятых (это уже не к вам), Sh0Ck_filE, уж извините, но аргумента против для offline-клиента (правда, не знаю, о чём речь) я не вижу. Ну разве что траффик может будет побольше. Конечно, если XML использовать по назначению - хранить данные на пользовательской машине вовсе необязательно в XML, XML нужен лишь для того, чтобы забрать данные с сервера и разобравшись в них положить к себе на машину в удобоваримом формате, коим XML быть не обязан. Это упрощает изменения на серверной и клиенсткой части, поскольку в этом случае, если добавляются/удаляются новые свойства, то старый клиент либо заполняет их по дефолту (если свойства были удалены), либо просто игнорирует то, чего он не поддерживает. При этом способ разбора полученных данных никак не меняется - что нельзя не назвать удобным. Аналогично с ситуацией с "новым" клиентом/"старым" сервером.

[Sh0Ck_filE]

<!--QuoteBegin-SiMM+Jan 18 2005, 12:25--><div class='quotetop'>QUOTE(SiMM @ Jan 18 2005, 12:25)</div><div class='quotemain'><!--QuoteEBegin-->Sh0Ck_filE, уж извините, но аргумента против для offline-клиента (правда, не знаю, о чём речь) я не вижу.
[right][snapback]160620[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Трафик сильно большой будет если хмл-ом кидать данные. А про хранение я не говорю, есессно <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

[Scalder]

Приятно хоть иногда поспорить по вопросу программирования на родном форуме ))
<!--QuoteBegin-SiMM+Jan 18 2005, 13:25--><div class='quotetop'>QUOTE(SiMM @ Jan 18 2005, 13:25)</div><div class='quotemain'><!--QuoteEBegin-->Иначе подобное (<item></item><item></item>) вообще невозможно было бы разобрать однозначно (то ли это два item'а, то ли это содержимое item'а соответствует </item><item>)
[right][snapback]160620[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
А кто сказал, что это не реализованно? И кт сказал, что это нужно убрать?
Я сказал о параметре тега, а не о его значении т.е.

Код: выделить все

<тэг парамер="значение_параметра">
значение тэга
</тэг>


Вполне возможно эта формилировка не стандартая, но я так это так понял...
<!--QuoteBegin-SiMM+Jan 18 2005, 13:25--><div class='quotetop'>QUOTE(SiMM @ Jan 18 2005, 13:25)</div><div class='quotemain'><!--QuoteEBegin-->А по поводу остального - во-первых, насколько я тебя понял, ты писал парсер под индивидуальную задачу, зная структуру документа & etc.
[right][snapback]160620[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
нет парсер универсальный и уже применяеться в следуещеё программе...
только отошел от некоторых требований xml (см. выше)

На счет обьёмов:
1) И сколько сообщений на форуме влезут в эти смешные 1 мб?
2) Берем озоновские списки например 50 мегов, 352*50 = 17,6 секунд..
это очень много? И это при чтении напрямую из архива с максимальным сжатием...
Не думаю, что при использовании другого формата и чтении из него данных в сжатом виде цифра получиться на порядок меньше...
И при этом формат универсальный и в его задачу быстродействие особо не входит...
(блин жутко не удобно отвечать на неструктурированный ответ, О!!! опять в xml всё по полочкам )) )

Про zip:
Как раз при делах, т.к. по и-нету ты не додумаешься ведь передавать его в незаархивированном виде?

Про Бд:
А я что говорил давайте писать БД на xml и файловые системы?
(хотя БД есть и работают не плохо... вроде в кашэ в БД используеться xml...
Скажи ещё тормозная технология? )) )

Про ответ Файлу:
блин, ты сам сказал что xml для экспорта/импорта и тут-же говоришь о том, что хранить БД в нем не надо... ну это и коню понятно!!!

А на счет поддержки апдейта:
Предложи плз. более удобный файл для этого...

Да и вообще мне кажеться твой ответ может быть по двум причинам:
1) Не совсем понимаешь о чем был мой пост
2) Ради поста?

Но всё равно спасибо...
Особенно за ОЗОН ))

p.s. Постарайся быть более структурированным ))
Может я просто привык и это прихоть, но мне кажеться так тебя будет читать и отвечать намного проще ))

2Sh0Ck_filE
"Младца!" ))

Послесловие:
Люди я тоже раньше очень негативно высказывался в адрес xml как формата данных, и парсеров...
Если вы посмотрите я тоже ни раз высказывался против использования его офффф... Но зачем изобретать велосипед?
По сути мы придем к тому-же...

[SiMM]

> И сколько сообщений на форуме влезут в эти смешные 1 мб?
Речь ведь не была о форуме? В твоём посте я такого слова не обнаружил (может просто слеп). Вообще если говорить об offline-клиенте, то, имхо, разумно копать в сторону NNTP (ибо необходимость в реализации клиента тут же отпадает).

> это очень много?
Да нет, немного. У меня PHP-шный скрипт конвертил это дело в файл с SQL-запросами где-то около минуты (может ошибаюсь - не помню уже - писал ради баловства, читал файл вообще посимвольно - вот как раз при таком раскладе, да и не только, очень удобно забирать всё между < и >, поскольку спецификация не допускает наличия этих символов внутри item'а - в итоге алгоритм парсинга получается довольно простым). Насчёт его универсальности я сейчас ничего не скажу - не помню, однако не считаю это неразрешимой проблемой. Я же лишь говорил о стандартных компонентах, которые обладают особенной тормознутостью.

> Как раз при делах, т.к. по и-нету ты не додумаешься ведь передавать его в незаархивированном виде?
Среда передачи данных к самому формату XML отношения не имеет, это вопрос десятый. А для работы с XML тебе в любом случае его придётся вначале его распаковать (хотя для ZIP'а вполне можно реализовать алгоритм, разжимающий на лету, но это просто слишком муторно и имхо не оправдано)

> ты сам сказал что xml для экспорта/импорта и тут-же говоришь о том, что хранить БД в нем не надо... ну это и коню понятно!!!
Разве первая часть твоего недовольства (xml для экспорта/импорта) как-то противоречит второй (хранить БД в xml не стоит)? Это пояснение скорее было предназначено Sh0Ck_filE, который не приводя аргументов отказался от XML.

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

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

> 2) Ради поста?
Наверно все посты я делаю исключительно для этого, и именно поэтому набрал за два с половиной года аж целых 199 сообщений

> Послесловие:
Всё, что я сказал - это то, что всему своё место. Описал, где XML удобен, а где он невыгоден. Если ты понял мой предыдущий пост как то иначе - то это твои личные проблемы восприятия действительности, пусть хоть и в частном случае.

[Scalder]

<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->Речь ведь не была о форуме? В твоём посте я такого слова не обнаружил (может просто слеп). Вообще если говорить об offline-клиенте, то, имхо, разумно копать в сторону NNTP (ибо необходимость в реализации клиента тут же отпадает).
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
И какой магией рук вы тогда собираетесь делать модерирование/одобрение в блог?<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->писал ради баловства, читал файл вообще посимвольно
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
тоже самое у меня )) А сейчас и так нормально работает, читать можно по 4 кб.. но лень переделывать да и другие дела пока есть...
хотя желание переделать есть...
<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->А для работы с XML тебе в любом случае его придётся вначале его распаковать (хотя для ZIP'а вполне можно реализовать алгоритм, разжимающий на лету, но это просто слишком муторно и имхо не оправдано)
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Но ведь я это сделал!!!
И я не считаю себя особо одренным программистом (наверное это по тому, что такая возможность есть в Java )) )
<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->Разве первая часть твоего недовольства (xml для экспорта/импорта) как-то противоречит второй (хранить БД в xml не стоит)? Это пояснение скорее было предназначено Sh0Ck_filE, который не приводя аргументов отказался от XML.
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
именно! Никак не противоречит, но я готов высказаться в сторону того, что XML не такой уж и тормозной формат... И привел пример. Всё зависит от кривизные реализации...
А идея всегда хороша ))
<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->Не понял юмора. А почему я его должен предлагать? По моему, я вполне доступно выразил свою точку зрения к вопросу.
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Просто обычно когда, о чем-то говорят, что это плохо или они сами сделали лучше или они знают где/кто сделал лучше...<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->У вас, к сожалению, форумы этому не способствуют - неудобно уж слишком. Было бы гораздо удобнее, если по нажатию на ник в случае наличия выделенного фрагмента он вставлялся в открытую форму быстрого ответа как цитата. При закрытой форме ответа или отсутствии выделения лично меня поведение при клике по нику вообще не интересует
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Снизу есть кнопка быстрого ответа - пользуй её.
Для вставки цитаты - выдели цитируемый текст и нажми в сообщении ответить.
<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->> 2) Ради поста?
Наверно все посты я делаю исключительно для этого, и именно поэтому набрал за два с половиной года аж целых 199 сообщений
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Решил меня за месяц догнать? )))<!--QuoteBegin-SiMM+Jan 19 2005, 00:33--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 00:33)</div><div class='quotemain'><!--QuoteEBegin-->> Послесловие:
Всё, что я сказал - это то, что всему своё место. Описал, где XML удобен, а где он невыгоден. Если ты понял мой предыдущий пост как то иначе - то это твои личные проблемы восприятия действительности, пусть хоть и в частном случае.
[right][snapback]160710[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Блин, ну неужели нельзя быть маленько не таким грубым?
Вообще ты зачем ходишь на этот форум?
Для того чтоб общаться, но тогда зачем говорить, что это мои личные проблемы...
Типа я скажу и на всё остальное пох?
(если захочешь тему о форуме продолжить плз не здесь)

[SiMM]

<!--QuoteBegin-Scalder+Jan 19 2005, 10:07--><div class='quotetop'>QUOTE(Scalder @ Jan 19 2005, 10:07)</div><div class='quotemain'><!--QuoteEBegin-->Просто обычно когда, о чем-то говорят, что это плохо или они сами сделали лучше или они знают где/кто сделал лучше...<!--QuoteEnd--></div><!--QuoteEEnd-->Я не сказал, что он лучше, я не говорил, что он хуже. Я лишь сказал, что у него есть своя ниша, и есть места, где он, на мой взгляд, неуместен, хотя бы потому, что уступает в производительности.<!--QuoteBegin-Scalder+Jan 19 2005, 10:07--><div class='quotetop'>QUOTE(Scalder @ Jan 19 2005, 10:07)</div><div class='quotemain'><!--QuoteEBegin-->я готов высказаться в сторону того, что XML не такой уж и тормозной формат<!--QuoteEnd--></div><!--QuoteEEnd-->Однако, надеюсь, оспаривать тот факт, что классическая реализация быстрее - ты, надеюсь, тоже не будешь? Хотя конечно можно навернуть к XML дополнительные приблуды типа индексов для ускорения процесса позиционирования - но это уже не классический XML, возможно, что-то вроде этого и хотят сделать в binary XML.<!--QuoteBegin-Scalder+Jan 19 2005, 10:07--><div class='quotetop'>QUOTE(Scalder @ Jan 19 2005, 10:07)</div><div class='quotemain'><!--QuoteEBegin-->ну неужели нельзя быть маленько не таким грубым?<!--QuoteEnd--></div><!--QuoteEEnd-->Сволочь я А вообще - грубости там не было - ты неправильно меня понял - я лишь указал на то, что ты неправ в своём понимании. Предлагаю оставить эту тему - если тебе так легче - я даже могу сказать, что ты прав.
А вообще, по теме - проблема в том, что большинство так называемых программеров (хотя я и сам не ахти - так, балуюсь маленько) не будет писать своих парсеров (хоть в этом и нет ничего сложного), а воспользуется готовеньким. Что касается PHP я неоднократно был свидетелем жалоб на то, как оно, готовенькое, глючно, медленно и требовательно к ресурсам.
Я думаю на этом тема себя исчерпала... пока наконец не станут известны детали реализации binary XML По крайней мере - мне добавить нечего.

[Scalder]

<!--QuoteBegin-SiMM+Jan 19 2005, 11:20--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 11:20)</div><div class='quotemain'><!--QuoteEBegin-->Я не сказал, что он лучше, я не говорил, что он хуже. Я лишь сказал, что у него есть своя ниша, и есть места, где он, на мой взгляд, неуместен, хотя бы потому, что уступает в производительности.
[right][snapback]160748[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
А я привел пример того, что его производительность не так уж и мала ))
<!--QuoteBegin-SiMM+Jan 19 2005, 11:20--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 11:20)</div><div class='quotemain'><!--QuoteEBegin-->Однако, надеюсь, оспаривать тот факт, что классическая реализация быстрее - ты, надеюсь, тоже не будешь? Хотя конечно можно навернуть к XML дополнительные приблуды типа индексов для ускорения процесса позиционирования - но это уже не классический XML, возможно, что-то вроде этого и хотят сделать в binary XML.
[right][snapback]160748[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
нет, просто скажу, что это геморнее для программиста(т.к. разобрать xml намного легче)
А классический подход не на много быстрее работает...
<!--QuoteBegin-SiMM+Jan 19 2005, 11:20--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 11:20)</div><div class='quotemain'><!--QuoteEBegin-->Сволочь я
[right][snapback]160748[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
аналогично )))
<!--QuoteBegin-SiMM+Jan 19 2005, 11:20--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 11:20)</div><div class='quotemain'><!--QuoteEBegin-->Что касается PHP я неоднократно был свидетелем жалоб на то, как оно, готовенькое, глючно, медленно и требовательно к ресурсам.
[right][snapback]160748[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
Это вопрос только "прямизны рук" )) И касаеться всего ПО...
видел и я когда запуск программы с MS SQL на 2*Xeon 1.5 ггц c 2 гига оперативы и на нем-же программа занимал по пол дня, и база при этом была мегов 200-300...(Что по сути копейки при практически любой структуре, даже кривой...)

<!--QuoteBegin-SiMM+Jan 19 2005, 11:20--><div class='quotetop'>QUOTE(SiMM @ Jan 19 2005, 11:20)</div><div class='quotemain'><!--QuoteEBegin-->Я думаю на этом тема себя исчерпала... пока наконец не станут известны детали реализации binary XML По крайней мере - мне добавить нечего.
[right][snapback]160748[/snapback][/right]
<!--QuoteEnd--></div><!--QuoteEEnd-->
согласен.