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

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

LP>>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода.
LP>> Что тут непонятного?
S>Непонятно, при чем тут HTTP. Ты говоришь исключительно о структуре документа, которая неважно, как передается. Может, читается с диска.
S>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные.

А если я хочу именно такой формат?

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

LP>А если я хочу именно такой формат?

Ни каких проблем. Можешь передавать какой угодно формат

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

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

LP>>Скажем, если в ячейке таблицы текст на 500 кбайт, браузер его будет получать при небыстром соединении сколько времени? Если бы структура документа передавалась бы вперед содержимого ячеек, то браузер смог бы отрисовать таблицу, а текст заполнять по мере его прихода.
LP>> Что тут непонятного?
S>Непонятно, при чем тут HTTP. Ты говоришь исключительно о структуре документа, которая неважно, как передается. Может, читается с диска.
S>То, чего ты хочешь, запросто достигается заменой HTML на такой формат, в котором сначала идет структура, а потом — данные.
LP>>Или хочешь сказать что способ формирования пакетов для передачи не является прерогативой протокола?

Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат? Что мешает точно таким же образом оптимизировать древовидные струткуры? Скажем, если клиент поддерживает эту фичу, он в методе GET явно указывает это, и сервер преобразовывает html или xml соотв. образом.

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

LP>Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат?

Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.

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

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

LP>>Может я и ошибаюсь в чем-то, но твоя неспособность понять банальные вещи просто удивляет. HTTP, например, поддерживает сжатие данных, gzip-ом к примеру. Архив gzip — чем не формат?

HB>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.

Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?

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 — это имя формата для представления структуры документа, оптимизированный именно для передачи деревянных структур.

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

LP>

LP>GET .../HTTP/1.1
LP>Host: 
LP> ...
LP>IntermediateFormat: format_name
LP>

LP>Здесь format_name — это имя формата для представления структуры документа, оптимизированный именно для передачи деревянных структур.


Все придумано до нас. Читать заголовок Content-type

Придумываешь формат для деревянных структур (а это что за звери?) и передаешь. Только учти, принимающий клиент должен знать, что с этим форматом делать.

Здравствуйте, LaPerouse, Вы писали:
LP>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
Ок, теперь понятно.
Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.

Здравствуйте, 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". Нужно вводить новый заголовок.

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

S>Здравствуйте, LaPerouse, Вы писали:
LP>>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
S>Ок, теперь понятно.
S>Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.

Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?

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

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

Content-Type: text/html
Content-Encoding: xmlpack

Так сойдет?

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

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

S>>Здравствуйте, LaPerouse, Вы писали:
LP>>>Что такое сжатие? Это преобразование html-документа в определенный формат, который может быть gzip-ом, zip-ом и т д. Я предлагаю, чтобы точно также при пересылке html, xml ТОЧНО ТАКЖЕ перегонялись в какой-нибудь третий формат. Сам собой, декларация всего этого должна быть в http, неужели это непонятно?
S>>Ок, теперь понятно.
S>>Никаких проблем: есть стандартизованный способ реализовывать такое поведение. Придумываешь свой дополнительный хидер — и вперед.

LP>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?

Изменение формата и расширение это разные вещи. Одно дело исправить исходники программы Far manager и собрать его заново, и совсем другое скачать плагин и установить.

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

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

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

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

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

HB>>Не так. HTTP поддерживает сжатие. Всё. Ограничений на формат http при этом не накладывает. Использование именно gzip — это выбор конкретных серверов и клиентов, использующих HTTP.
LP>Что такое сжатие? Это преобразование html-документа в определенный формат,

Нет там никакого преобразования, есть сжатие, HTML-документ остаётся тем же самым.

Здравствуйте, LaPerouse, Вы писали:
LP>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?
Это документированное расширение протокола.
Вот, например, RFC 3229. Парни предложили способ передавать не все данные, а только ту часть, которая изменилась.
Ввели, как водится, несколько новых хидеров — и вот, пожалуйста, всё в порядке: клиент выражает желание, а сервер, если может, осуществляет возможность.
Потом другие парни придумали свой способ представления дельты, ориентированный на ATOM и RSS. И вперед, на танки.
При этом если клиент не выразил свое желание поддержать эти фичи, сервер не имеет права их ему навязывать.
И клиент не имеет права рассчитывать, что сервер ему отдаст всё как запрошено.

И это — штатная фича. Сейчас на практике применяется довольно много расширений к оригинальному HTTP, но это не делает ни клиентов, ни серверы нарушителями протокола.

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

S>Здравствуйте, LaPerouse, Вы писали:
LP>>Может быть я и ошибаюсь, но разве это не есть изменение протокола HTTP?
S>Это документированное расширение протокола.
S>Вот, например, RFC 3229. Парни предложили способ передавать не все данные, а только ту часть, которая изменилась.
S>Ввели, как водится, несколько новых хидеров — и вот, пожалуйста, всё в порядке: клиент выражает желание, а сервер, если может, осуществляет возможность.
S>Потом другие парни придумали свой способ представления дельты, ориентированный на ATOM и RSS. И вперед, на танки.
S>При этом если клиент не выразил свое желание поддержать эти фичи, сервер не имеет права их ему навязывать.
S>И клиент не имеет права рассчитывать, что сервер ему отдаст всё как запрошено.

S>И это — штатная фича. Сейчас на практике применяется довольно много расширений к оригинальному HTTP, но это не делает ни клиентов, ни серверы нарушителями протокола.

Я ни про одно расширение HTTP до этого не слышал и не знал, что определение новых заголовков документировано. Поэтому отчасти признаю свою неправоту. Но справедливости ради, вы тоже должны признать, что стандартный набор заголовков, описанный в 1.1, не позволяют явным образом проделать такие манипуляции.