Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали: LP>>HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ. S>HTTP уже поддерживает способ, удобный для передачи и принятия.
Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода. Что тут непонятного? Или хочешь сказать что способ формирования пакетов для передачи не является прерогативой протокола?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа.
Нельзя. В HTML нет такого понятия как "видимая структура", есть просто структура документа, видимой её делает браузер. Что отображать, а что нет, зависит от правил зашитых в браузере, а также от внешних правил типа CSS.
Здравствуйте, LaPerouse, Вы писали:
S>>Здравствуйте, Mamut, Вы писали: M>>>Думаю, это не недостаток именно http, а браузеров и html S>>Ничего, тут и поопытнее люди протокол от формата в упор отличить не могут. LP>Т. е. я не могу отличить html от http?
Ты считаешь, что они как-то связаны. На деле они не связаны (и более того, не должны быть связаны) никак.
Можете смеяться сколько угодно, но я считаю, что http недостаточно прикладной, хотя и используется в подавляющем большинстве случаев для передачи xml-html подобных текстовых форматов с древовидной структурой, но для этого не оптимизирован. Например,
где table — огроменная таблица килобайт на 500. Можно было бы обойтись без сложных эвристик в браузерах для рендеринга недоползшего содержимого, если бы скажем, страница передавалась как-то так (формат может быть любой, хоть бинарный):
Здравствуйте, LaPerouse, Вы писали:
LP>Я принял 400 грамм на грудь...
Так с этого и надо было начинать — мы-то думали, ты все это всерьез рассказываешь.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, LaPerouse, Вы писали:
LP>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода. LP> Что тут непонятного?
Непонятно, при чем тут HTTP. Ты говоришь исключительно о структуре документа, которая неважно, как передается. Может, читается с диска.
То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные. LP>Или хочешь сказать что способ формирования пакетов для передачи не является прерогативой протокола?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.
Э... Не в этом мире. То что ты предлагаешь — это кардинальная ревизия HTML. Основывай свой комитет по стандартизации и продвигай. Но для современного HTML (и соотв. современных браузеров) это работать не будет — ты забыл про наличие CSS и про то что текст (его длинна, а зачастую и содержание) влияет на то где будут расположены элементы документа.
Здравствуйте, LaPerouse, Вы писали:
LP>у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.
Дык это браузер должен понимать, откуда брать контент. Http-то тут причем?
Здравствуйте, LaPerouse, Вы писали: LP>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?
Это документированное расширение протокола.
Вот, например, RFC 3229. Парни предложили способ передавать не все данные, а только ту часть, которая изменилась.
Ввели, как водится, несколько новых хидеров — и вот, пожалуйста, всё в порядке: клиент выражает желание, а сервер, если может, осуществляет возможность.
Потом другие парни придумали свой способ представления дельты, ориентированный на ATOM и RSS. И вперед, на танки.
При этом если клиент не выразил свое желание поддержать эти фичи, сервер не имеет права их ему навязывать.
И клиент не имеет права рассчитывать, что сервер ему отдаст всё как запрошено.
И это — штатная фича. Сейчас на практике применяется довольно много расширений к оригинальному HTTP, но это не делает ни клиентов, ни серверы нарушителями протокола.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
LP>где table — огроменная таблица килобайт на 500. Можно было бы обойтись без сложных эвристик в браузерах для рендеринга недоползшего содержимого, если бы скажем, страница передавалась как-то так (формат может быть любой, хоть бинарный):
LP><html alias='1' parent=0><body alias=2 parent=0><table alias=3 parent=2><tr alias=4 parent=3>...
Думаю, это не недостаток именно http, а браузеров и html
Здравствуйте, LaPerouse, Вы писали: LP>HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ.
HTTP уже поддерживает способ, удобный для передачи и принятия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные.
+1
Более того — решается даже уже существующими средствами — грузи сначала чистый документ, а потом скриптом догружай данные.
Здравствуйте, Mamut, Вы писали:
M>HTTP может спокойно передавать такой код кусками по требованию, для этого в нем есть Chunked Transfer (на основе которого построена, например, докачка файлов по HTTP)
M>В HTTP возмоность передачи информации кусками есть
Вообще-то докачка реализуется средствами Ranges, а ни как не Chunked Transfer. Чанки используются в случае, когда размер контента не определен (хотя их можно использовать и при известном размере).
Здравствуйте, LaPerouse, Вы писали:
LP>Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат?
Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, LaPerouse, Вы писали: LP>>>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно? S>>Ок, теперь понятно. S>>Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.
LP>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?
Изменение формата и расширение это разные вещи. Одно дело исправить исходники программы Far manager и собрать его заново, и совсем другое скачать плагин и установить.
LP>1. CSS. должен передаваться вместе с тегами. Основное содержимое документа — именно текст. LP>2. Дело в том, что современные браузеры пытаются предугадывать разметку, имея половину html-документа. Получается весьма плачевно, но факт состоит в том, что они пытаются. Ежу понятно, что предугадать вид документа легче, имея перед собой структуру документа (пусть и размер содержимого неизвестен) в отличие от случая, когда перед нами его часть с половиной незакрытых тегов, и нужно придумывать эвристики для расстановки замыкающих тегов.
А оно вообще нужно — предугадывать разметку? Время модемов на 14400 закончилось. К тому же длиннючая страница с большим количеством текста внутри какой-то сильно вложенной страницы — случай как правило клинический, нормальные дизайнеры современный дизайн страниц так не делают.
К тому же твоё решение — половинчатое, т.е. при довольно неплохих накладных расходах (модификация протокола, модификация страниц, модификация браузеров) оно не устранит проблему полностью а лишь слегка (а насколько, кстати? я вот совсем не в курсе как алгоритмы предугадывания работают) облегчит задачу браузерам.
L>К тому же твоё решение — половинчатое, т.е. при довольно неплохих накладных расходах (модификация протокола, модификация страниц, модификация браузеров) оно не устранит проблему полностью а лишь слегка (а насколько, кстати? я вот совсем не в курсе как алгоритмы предугадывания работают) облегчит задачу браузерам.
Никак не облегчит. Потому что текст, картинки и прочие данные — это тоже не хухры-мухры, они имеют физические размеры, для них надо вычислять всякую интересную фигню вроде размера, занимаемого ими на экране и т.п., после чего все равно придется делать reflow/redraw всего документа. Что они и так сейчас делают. То есть меняем шило на мыло
Здравствуйте, Left2, Вы писали:
L>При чём тут HTTP? Я тут вижу только претензии к HTML.
HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Mamut, Вы писали: M>Думаю, это не недостаток именно http, а браузеров и html
Ничего, тут и поопытнее люди протокол от формата в упор отличить не могут.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Mamut, Вы писали: M>>Думаю, это не недостаток именно http, а браузеров и html S>Ничего, тут и поопытнее люди протокол от формата в упор отличить не могут.
Т. е. я не могу отличить html от http?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Left2, Вы писали:
L>>При чём тут HTTP? Я тут вижу только претензии к HTML.
LP>HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ.
Здравствуйте, LaPerouse, Вы писали:
LP>HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ.
Непонятно, 90% от чего, от количества запросов или от объема? Допустим, от количества запросов. Прикинем, что же у нас скачивается при открытии http://rsdn.ru (собрано Firebug-ом, дублирующиеся запросы убраны, кэш сброшен):
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, LaPerouse, Вы писали:
LP>>Здравствуйте, Left2, Вы писали:
L>>>При чём тут HTTP? Я тут вижу только претензии к HTML.
LP>>HTML — это формат представления, http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура). HTML имеет форму, удобную для ПРЕДСТАВЛЕНИЯ, http должен поддерживать способ, удобный для ПЕРЕДАЧИ и ПРИНЯТИЯ.
M>http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
M>Пункт 3.6.1, Chunked Transfer
M>А также подумать, каким способом достигается такой магический момент, как докачка файлов
M>То, что HTML нельзя таким образом передавать и потом отображать, это проблемы HTML'я
HTML всего лишь формат представления, абстрагированный от передачи.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
M>>http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
M>>Пункт 3.6.1, Chunked Transfer
M>>А также подумать, каким способом достигается такой магический момент, как докачка файлов
M>>То, что HTML нельзя таким образом передавать и потом отображать, это проблемы HTML'я
LP>HTML всего лишь формат представления, абстрагированный от передачи.
это исключительно проблема браузеров и стандарта ХТМЛ, который не предусматривает способ отображения такого кода.
HTTP может спокойно передавать такой код кусками по требованию, для этого в нем есть Chunked Transfer (на основе которого построена, например, докачка файлов по HTTP)
В HTTP возмоность передачи информации кусками есть
Здравствуйте, WFrag, Вы писали:
WF>Непонятно, 90% от чего, от количества запросов или от объема? Допустим, от количества запросов.
.... WF>И где тут 90% древообразного XML?
А вот если посчитать от объема, да еще в целом по Сети... то 90% будет видео и графика в формате порнухи
Здравствуйте, LaPerouse, Вы писали:
LP>http — протокол передачи этого формата (и не только, но в 90 процентах случаев это древообразная xml-подобная структура).
Это сильно вряд ли. Если, скажем, посмотреть на запросы, которые посылает браузер, то можно будет утверждать, что "в 75% случаев это двоичные данные, содержащие изображение в формате jpeg или gif".
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, LaPerouse, Вы писали:
LP>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода. Что тут непонятного? Или хочешь сказать что способ формирования пакетов для передачи не является прерогативой протокола?
Посмотри XML + XSL (xslt)
Это всего лишь проблема браузеров, но никак не протокола.
Здравствуйте, Left2, Вы писали:
S>>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные. L>+1 L>Более того — решается даже уже существующими средствами — грузи сначала чистый документ, а потом скриптом догружай данные.
Это уже динамика
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода. LP>> Что тут непонятного? S>Непонятно, при чем тут HTTP. Ты говоришь исключительно о структуре документа, которая неважно, как передается. Может, читается с диска. S>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные.
А если я хочу именно такой формат?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода. LP>> Что тут непонятного? S>Непонятно, при чем тут HTTP. Ты говоришь исключительно о структуре документа, которая неважно, как передается. Может, читается с диска. S>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные. LP>>Или хочешь сказать что способ формирования пакетов для передачи не является прерогативой протокола?
Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат? Что мешает точно таким же образом оптимизировать древовидные струткуры? Скажем, если клиент поддерживает эту фичу, он в методе GET явно указывает это, и сервер преобразовывает html или xml соотв. образом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Hobot Bobot, Вы писали:
HB>Здравствуйте, LaPerouse, Вы писали:
LP>>Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат?
HB>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
H>Вообще-то докачка реализуется средствами Ranges, а ни как не Chunked Transfer. Чанки используются в случае, когда размер контента не определен (хотя их можно использовать и при известном размере).
Здравствуйте, Hobot Bobot, Вы писали:
HB>Здравствуйте, LaPerouse, Вы писали:
LP>>Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат?
HB>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
GET .../HTTP/1.1
Host:
...
IntermediateFormat: format_name
Здесь format_name — это имя формата для представления структуры документа, оптимизированный именно для передачи деревянных структур.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
Никто не мешает твоему серверу декларировать протокол сжатия “xmlpack”, а клиенту его понимать. Для этого не надо менять HTTP, надо просто написать соответствующую RFC и заставить производителей браузеров её поддержать.
Здравствуйте, LaPerouse, Вы писали:
LP>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
И в чем проблема? Перегоняешь, а потом Content-Type назначаешь свой "superFormat". Если клиент готов обработать "superFormat" -- он его обработает. Все
Здравствуйте, LaPerouse, Вы писали:
HB>>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
LP>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
Единственный смысл добавления поддержки сжатия непосредственно в протокол HTTP — это прозрачность сжатия для логики приложения. Браузеру или RSDN@Home (после того, как документ получен) все равно, использовалось ли сжатие при передаче или нет.
В Вашем случае, приложению, отвественному за отображение полученных данных, все равно придется уметь работать с этим новым форматом.
В чем тогда разница между предложенным Вами и простым указанием
Content-Type: text/laperouse-own-format?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
LP>Здесь format_name — это имя формата для представления структуры документа, оптимизированный именно для передачи деревянных структур.
Все придумано до нас. Читать заголовок Content-type
Придумываешь формат для деревянных структур (а это что за звери?) и передаешь. Только учти, принимающий клиент должен знать, что с этим форматом делать.
Здравствуйте, LaPerouse, Вы писали: LP>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
Ок, теперь понятно.
Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Hobot Bobot, Вы писали:
HB>Здравствуйте, LaPerouse, Вы писали:
HB>>>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
LP>>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
HB>Единственный смысл добавления поддержки сжатия непосредственно в протокол HTTP — это прозрачность сжатия для логики приложения. Браузеру или RSDN@Home (после того, как документ получен) все равно, использовалось ли сжатие при передаче или нет.
Точно также и с этим форматом.
HB>В Вашем случае, приложению, отвественному за отображение полученных данных, все равно придется уметь работать с этим новым форматом.
HB>В чем тогда разница между предложенным Вами и простым указанием HB>Content-Type: text/laperouse-own-format?
Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали: LP>>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно? S>Ок, теперь понятно. S>Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.
Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.
Ну, так на добавление собственных заголовков HTTP тоже ограничений не накладывает.
Но, честно говоря, мне не очень понятно как такое прозрачное преобразование будет работать — даже если удастся произвольный HTML разобрать на структуру и данные, для того, чтобы собрать его обратно прозрачно для приложения, придется дождаться загрузки всего документа.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, LaPerouse, Вы писали:
HB>>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP. LP>Что такое сжатие? Это преобразование html-документа в определенный формат,
Нет там никакого преобразования, есть сжатие, HTML-документ остаётся тем же самым.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали: LP>>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP? S>Это документированное расширение протокола. S>Вот, например, RFC 3229. Парни предложили способ передавать не все данные, а только ту часть, которая изменилась. S>Ввели, как водится, несколько новых хидеров — и вот, пожалуйста, всё в порядке: клиент выражает желание, а сервер, если может, осуществляет возможность. S>Потом другие парни придумали свой способ представления дельты, ориентированный на ATOM и RSS. И вперед, на танки. S>При этом если клиент не выразил свое желание поддержать эти фичи, сервер не имеет права их ему навязывать. S>И клиент не имеет права рассчитывать, что сервер ему отдаст всё как запрошено.
S>И это — штатная фича. Сейчас на практике применяется довольно много расширений к оригинальному HTTP, но это не делает ни клиентов, ни серверы нарушителями протокола.
Я ни про одно расширение HTTP до этого не слышал и не знал, что определение новых заголовков документировано. Поэтому отчасти признаю свою неправоту. Но справедливости ради, вы тоже должны признать, что стандартный набор заголовков, описанный в 1.1, не позволяют явным образом проделать такие манипуляции.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, LaPerouse, Вы писали:
LP>>Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.
WF>Content-Type: text/html WF>Content-Encoding: xmlpack
WF>Так сойдет?
[quote]
All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.11) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding.
[/quote]
На практике конечно можно потребовать от сервера, чтобы он в ответ на соотв. значение этого параметра возвращал соотв. образом обработанный xml, но это не соответствует назначению этого поля, потому никто rfc под это делать не будет. Изменения, о которых я говорю, по сути есть изменение на уровне семантики, а не простое кодирование текстовой последовательности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>На практике конечно можно потребовать от сервера, чтобы он в ответ на соотв. значение этого параметра возвращал соотв. образом обработанный xml, но это не соответствует назначению этого поля, потому никто rfc под это делать не будет. Изменения, о которых я говорю, по сути есть изменение на уровне семантики, а не простое кодирование текстовой последовательности.
Можно сжулить и сделать вид, что это преобразование — типа gzip, просто преобразование text->text. А браузер научить, что если приходят данные в таком сжатии, то не надо их полностью “распаковывать” и отрисовывать (хотя этот вариант тоже возможен, просто у него нет никаких плюсов), а сразу начать их рисовать.
Здравствуйте, WFrag, Вы писали:
WF>Можно сжулить и сделать вид, что это преобразование — типа gzip, просто преобразование text->text. А браузер научить, что если приходят данные в таком сжатии, то не надо их полностью “распаковывать” и отрисовывать (хотя этот вариант тоже возможен, просто у него нет никаких плюсов), а сразу начать их рисовать.
Хотя в таком варианте надо чтобы преобразование было обратимым, с точностью до пробелов и комментариев...
Здравствуйте, Hobot Bobot, Вы писали:
HB>Здравствуйте, LaPerouse, Вы писали:
LP>>Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.
HB>Ну, так на добавление собственных заголовков HTTP тоже ограничений не накладывает.
HB>Но, честно говоря, мне не очень понятно как такое прозрачное преобразование будет работать — даже если удастся произвольный HTML разобрать на структуру и данные, для того, чтобы собрать его обратно прозрачно для приложения, придется дождаться загрузки всего документа.
Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Hobot Bobot, Вы писали:
HB>>Здравствуйте, LaPerouse, Вы писали:
LP>>>Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.
HB>>Ну, так на добавление собственных заголовков HTTP тоже ограничений не накладывает.
HB>>Но, честно говоря, мне не очень понятно как такое прозрачное преобразование будет работать — даже если удастся произвольный HTML разобрать на структуру и данные, для того, чтобы собрать его обратно прозрачно для приложения, придется дождаться загрузки всего документа.
LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.
То есть отдельно — в том же потоке, но скажем, ближе к концу, чтобы браузеры, быстро считав начало потока, уже могли отобразить хотя бы часть html-документа.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, LaPerouse, Вы писали:
LP>>На практике конечно можно потребовать от сервера, чтобы он в ответ на соотв. значение этого параметра возвращал соотв. образом обработанный xml, но это не соответствует назначению этого поля, потому никто rfc под это делать не будет. Изменения, о которых я говорю, по сути есть изменение на уровне семантики, а не простое кодирование текстовой последовательности.
WF>Можно сжулить и сделать вид, что это преобразование — типа gzip, просто преобразование text->text. А браузер научить, что если приходят данные в таком сжатии, то не надо их полностью “распаковывать” и отрисовывать (хотя этот вариант тоже возможен, просто у него нет никаких плюсов), а сразу начать их рисовать.
Собственно говоря, отрисовав скелет документа, остальное можно допихать, либо с помощью dhtml, генеря соотв. js, либо пользусь библиотечными средствами браузера для доведения dom до кондиции. В общем, в техническом плане проблем нет, это просто вопрос восприятия данного формата.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.
LP>То есть отдельно — в том же потоке, но скажем, ближе к концу, чтобы браузеры, быстро считав начало потока, уже могли отобразить хотя бы часть html-документа.
Firefox и Opera это давно умеют делать. Причем тут HTTP?
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, LaPerouse, Вы писали:
LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа.
A>Нельзя. В HTML нет такого понятия как "видимая структура", есть просто структура документа, видимой её делает браузер. Что отображать, а что нет, зависит от правил зашитых в браузере, а также от внешних правил типа CSS.
Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?
Здравствуйте, LaPerouse, Вы писали:
A>>Нельзя. В HTML нет такого понятия как "видимая структура", есть просто структура документа, видимой её делает браузер. Что отображать, а что нет, зависит от правил зашитых в браузере, а также от внешних правил типа CSS. LP>Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?
Бритвооккамство.
LP><td> LP><a>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</a> LP><td> LP>передавай ты содержимое тега a в конце потока.
Это будет уже не HTML, а какой-то другой формат. Нужды в нём сейчас нет, поскольку браузеры уже умеют отрисовывать документ до полного его получения, а для других целей есть SAX-парсеры.
LP>Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?
LP><td> LP><a>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</a> LP><td>
LP>передавай ты содержимое тега a в конце потока.
Для этого тебе надо создать свой собственный формат, протолкнуть его как стандарт и обязать браузеры поддерживать его. При чем тут HTTP?
ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.
Здравствуйте, Mamut, Вы писали:
M>ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.
Я так понимаю, что имеется в виду случай, когда есть, скажем, 2 кб разметки и 2 мб данных.
А в остальном согласен, я тоже никак не пойму, при чем тут HTTP.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Left2, Вы писали:
LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.
L>Э... Не в этом мире. То что ты предлагаешь — это кардинальная ревизия HTML. Основывай свой комитет по стандартизации и продвигай. Но для современного HTML (и соотв. современных браузеров) это работать не будет — ты забыл про наличие CSS и про то что текст (его длинна, а зачастую и содержание) влияет на то где будут расположены элементы документа.
1. CSS. должен передаваться вместе с тегами. Основное содержимое документа — именно текст.
2. Дело в том, что современные браузеры пытаются предугадывать разметку, имея половину html-документа. Получается весьма плачевно, но факт состоит в том, что они пытаются. Ежу понятно, что предугадать вид документа легче, имея перед собой структуру документа (пусть и размер содержимого неизвестен) в отличие от случая, когда перед нами его часть с половиной незакрытых тегов, и нужно придумывать эвристики для расстановки замыкающих тегов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Mamut, Вы писали:
LP>>Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?... LP>>передавай ты содержимое тега a в конце потока. M>Для этого тебе надо создать свой собственный формат, протолкнуть его как стандарт и обязать браузеры поддерживать его. При чем тут HTTP? M>ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.
У тебя нет ни капли воображения? Я принял 400 грамм на грудь (корпоративка), у меня и то хватает способности додумать, что браузер получит структуру документа влет (ее при самом монструозном дизайне не должно быть больше 100 кбайт), а тормоза будут как раз при принятии остальной части документа. Представь себе случай:
у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.
Выпад в адрес участников форума удалён. Следите за словами. ДХ
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
M>>ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.
LP>У тебя нет ни капли воображения? Я принял 400 грамм на грудь (корпоративка), у меня и то хватает способности додумать, что браузер получит структуру документа влет (ее при самом монструозном дизайне не должно быть больше 100 кбайт), а тормоза будут как раз при принятии остальной части документа.
Как текст сможет это отразить, если у нас есть три блока, в каждом из которых текст разной длины? При получении данных ему все равно придется перерисовать все с учетом довольно сложных правил отрисовки.
Более того, каждое из отсылаемых данных тебе придется дополнительно пометить, как принадлежащее тому или иному тэгу
Объясни, что такое "отображать", если данных нет. Показывать пустую страницу?
И как это все относится к HTTP?
LP>у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.
Предлагаю посмотреть, как работают Файрфокс и Опера на медленных соединениях. Они именно это и делают.
