>>>>> Что-то много текстопротокольного фанатизма, протоколы это не >>>>> художественная >>>>> литература, бинарные протоколы это норма, никто не заставляет руками >>>>> набирать >>>>> бинарные сообщения в hex редакторе, всегда есть/можно написать простую >>>>> утилиту >>>>> которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть >>>>> отладочную инфу нет смысла все сто лет иметь оверхед от текстового >>>>> протокола >>>> >>>> пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо >>>> что-то пропустил >> И>>> Для начала, стоит наверное определится что такое текстовый протокол. И>>> Если понимать под этим символьное (UTF,koi) представление данных и служебной И>>> информации, то в этом случае объем передаваемой информации больше, чем у как И>>> то кодированого. Больше объем - больше требуется ресурсов. В качестве примера И>>> можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер исходника, И>>> компилятор,java машина) против бинарной программы на СИ. И>>> Я считаю, что тут проблема не в самих протоколах, а в том как их И>>> используют. Мегабайтные странички в памяти и браузер сжирающий процессор это И>>> писец - но это не проблема в самом протоколе http. >> >> И не в протоколе HTML. Память и процессор он сжирает вовсе даже >> бинарными структурами. >>
> Это какими? Если исключить flash и медиа, то остается js со всякими > json,xml,css, cookies.Есть еще вроде gzip не текстовый но позволяет > быстрее передать текстовые мегабайты. Что то еще? html парсится в DOM, на стадии парсинга и передачи по сети накладные расходы если посчитать и сравнить их с расходами на рендеринг, наложение стилей и прочая прочая, то получится что парсинг html - самая простая задача. решается где-то 500-ми строк кода парсера. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
