Здравствуйте, 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 под это делать не будет. Изменения, о которых я говорю, по сути есть изменение на уровне семантики, а не простое кодирование текстовой последовательности.

Здравствуйте, 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> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.

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

LP>Здравствуйте, Hobot Bobot, Вы писали:

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

LP>>>Ничего подобного. Content-Type будет "text/html". Нужно вводить новый заголовок.

HB>>Ну, так на добавление собственных заголовков HTTP тоже ограничений не накладывает.

HB>>Но, честно говоря, мне не очень понятно как такое прозрачное преобразование будет работать — даже если удастся произвольный HTML разобрать на структуру и данные, для того, чтобы собрать его обратно прозрачно для приложения, придется дождаться загрузки всего документа.


LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.

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

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

LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа.

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

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

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

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

WF>Можно сжулить и сделать вид, что это преобразование — типа gzip, просто преобразование text->text. А браузер научить, что если приходят данные в таком сжатии, то не надо их полностью “распаковывать” и отрисовывать (хотя этот вариант тоже возможен, просто у него нет никаких плюсов), а сразу начать их рисовать.

Собственно говоря, отрисовав скелет документа, остальное можно допихать, либо с помощью dhtml, генеря соотв. js, либо пользусь библиотечными средствами браузера для доведения dom до кондиции. В общем, в техническом плане проблем нет, это просто вопрос восприятия данного формата.

LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.

LP>То есть отдельно — в том же потоке, но скажем, ближе к концу, чтобы браузеры, быстро считав начало потока, уже могли отобразить хотя бы часть html-документа.

Firefox и Opera это давно умеют делать. Причем тут HTTP?

LP>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.

Э... Не в этом мире. То что ты предлагаешь — это кардинальная ревизия HTML. Основывай свой комитет по стандартизации и продвигай. Но для современного HTML (и соотв. современных браузеров) это работать не будет — ты забыл про наличие CSS и про то что текст (его длинна, а зачастую и содержание) влияет на то где будут расположены элементы документа.

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

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

LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа.

A>Нельзя. В HTML нет такого понятия как "видимая структура", есть просто структура документа, видимой её делает браузер. Что отображать, а что нет, зависит от правил зашитых в браузере, а также от внешних правил типа CSS.

Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?

<td>
<a>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</a>
<td>

передавай ты содержимое тега a в конце потока.

Здравствуйте, 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.

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

LP>>Любой HTML-документ имеет четко определенную структуру. Можно выделить набор тегов, которые определяют ВИДИМУЮ структуру документа. Например, тег table, td, td и т п относятся к таковым, а вот <a>, <p> и т п не относятся. Честно говоря, можно и не опускаться до этого и передавать все теги вместе, просто содержимое алиасить и передавать отдельно.

L>Э... Не в этом мире. То что ты предлагаешь — это кардинальная ревизия HTML. Основывай свой комитет по стандартизации и продвигай. Но для современного HTML (и соотв. современных браузеров) это работать не будет — ты забыл про наличие CSS и про то что текст (его длинна, а зачастую и содержание) влияет на то где будут расположены элементы документа.

1. CSS. должен передаваться вместе с тегами. Основное содержимое документа — именно текст.
2. Дело в том, что современные браузеры пытаются предугадывать разметку, имея половину html-документа. Получается весьма плачевно, но факт состоит в том, что они пытаются. Ежу понятно, что предугадать вид документа легче, имея перед собой структуру документа (пусть и размер содержимого неизвестен) в отличие от случая, когда перед нами его часть с половиной незакрытых тегов, и нужно придумывать эвристики для расстановки замыкающих тегов.

LP>1. CSS. должен передаваться вместе с тегами. Основное содержимое документа — именно текст.
LP>2. Дело в том, что современные браузеры пытаются предугадывать разметку, имея половину html-документа. Получается весьма плачевно, но факт состоит в том, что они пытаются. Ежу понятно, что предугадать вид документа легче, имея перед собой структуру документа (пусть и размер содержимого неизвестен) в отличие от случая, когда перед нами его часть с половиной незакрытых тегов, и нужно придумывать эвристики для расстановки замыкающих тегов.
А оно вообще нужно — предугадывать разметку? Время модемов на 14400 закончилось. К тому же длиннючая страница с большим количеством текста внутри какой-то сильно вложенной страницы — случай как правило клинический, нормальные дизайнеры современный дизайн страниц так не делают.

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

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

LP>>Скажи, какая религия мешает тебе передавать все статичное содержимое в конце HTML-потока?...
LP>>передавай ты содержимое тега a в конце потока.
M>Для этого тебе надо создать свой собственный формат, протолкнуть его как стандарт и обязать браузеры поддерживать его. При чем тут HTTP?
M>ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.

У тебя нет ни капли воображения? Я принял 400 грамм на грудь (корпоративка), у меня и то хватает способности додумать, что браузер получит структуру документа влет (ее при самом монструозном дизайне не должно быть больше 100 кбайт), а тормоза будут как раз при принятии остальной части документа. Представь себе случай:

<table>
<tr>
<td>
<a>aaaaaaaaaaaaaaa..aaa</a>
</td>
</td>
<td>
<a>bbbbbbbbbbbbbbbbbbbb...bb</a>
</td>
</tr>
</table>

Часть

<table>
<tr>
<td>
<a></a>
</td>
</td>
<td>
<a></a>
</td>
</tr>
</table>

у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.

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

LP>у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.

Дык это браузер должен понимать, откуда брать контент. Http-то тут причем?

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

LP>Я принял 400 грамм на грудь...

Так с этого и надо было начинать — мы-то думали, ты все это всерьез рассказываешь.

M>>ЗЫ. Покажи мне как браузер начнет "показывать содержимое сраз по получении части данных", если содержимое тэгов ты в самом конце предлагаешь передать.

LP>У тебя нет ни капли воображения? Я принял 400 грамм на грудь (корпоративка), у меня и то хватает способности додумать, что браузер получит структуру документа влет (ее при самом монструозном дизайне не должно быть больше 100 кбайт), а тормоза будут как раз при принятии остальной части документа.


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

Более того, каждое из отсылаемых данных тебе придется дополнительно пометить, как принадлежащее тому или иному тэгу

Объясни, что такое "отображать", если данных нет. Показывать пустую страницу?

И как это все относится к HTTP?


LP>у тя бразуер примет влет. Содержимое первого тега он будет вытягивать за 1 минуту. Но после того, как он ее вытянет, он тут же сможет ее отобразить. И оставитить к примеру 50 процентов места для второго столбца. Сегодня же, вытянув содержимое первого тега, браузер даже не будет знать, есть ли еще ячейки в этом столбце.


Предлагаю посмотреть, как работают Файрфокс и Опера на медленных соединениях. Они именно это и делают.


Могу даже скринкаст сделать, если надо

L>К тому же твоё решение — половинчатое, т.е. при довольно неплохих накладных расходах (модификация протокола, модификация страниц, модификация браузеров) оно не устранит проблему полностью а лишь слегка (а насколько, кстати? я вот совсем не в курсе как алгоритмы предугадывания работают) облегчит задачу браузерам.

Никак не облегчит. Потому что текст, картинки и прочие данные — это тоже не хухры-мухры, они имеют физические размеры, для них надо вычислять всякую интересную фигню вроде размера, занимаемого ими на экране и т.п., после чего все равно придется делать reflow/redraw всего документа. Что они и так сейчас делают. То есть меняем шило на мыло