От And
К Дмитрий Лебедев
Дата 25.04.2001 22:21:54
Рубрики Техподдержка;

Re: Модератору

Не морочьте голову себе и Новику. Если вас устроит такой же офф-лайн архив, какой я делал для by.ru, тогда -- немного терпения. Все, что нужно, можно получить с сервера даже не спрашивая разработчика, причем HTML здесь намного более легкий, чем на by.ru (чего стоит только , при каждом сообщении, где [ххх] есть имя файла, и более логичная структура HTML, где по nextSibling or nextNode легко бежится по нити. Меня до сих пор мутит, как вспомню, что обещал вам архив 10тыс одним файлом и придется-таки мне доморочить HTML с by.ru). Я уже сейчас забираю с этого форума, web.referent.ru, в течение 3-4 минут все только новые сообщения и позже читаю их офф-лайн. Если интересно, ссылка на код лежит здесь:
http://eliot96.narod.ru/forumKM/CommVBS.html
или сразу
http://eliot96.narod.ru/forumKM/LookForNewMessage.html

Про NNTP. На первый взгляд кажется, что всё дело именно в порте 119, так как ньюсридеры по умолчанию держат в настройках его. Однако НетСцап при добавлении сервера позволяет указать другой порт. Почему бы не указать и выше 2000? Однако речь должна идти не о лобовом решении -- поставить ньюссервер, (делать больше нечего владельцу сервера, как устанавливать софт и открывать 119 порт), а нужно рассматривать протокол NNTP как черный ящик. Работает он изумительно [rfc977], и никакой конкуренции ему web-based конференции не составят. Самое основное, что делает этот черный ящик, он очень экономно использует канал связи. Все, что было загружено, сразу становится архивом для чтения офф-лайн. Причем именно в офф-лайн возможна сортировка по нитям, по теме, по автору, по дате, по размеру и т.д., конструирование запроса на поиск отдельных слов. Логика работы (рассказываю на память, точнее посмотрите в rfc) --> при выборе пользователем нюсгруппы происходит загрузка локального файла-архива ранее полученных сообщений, на основании чего генерируется запрос серверу. На основании ответа сервера происходит синхронизация, то есть убираются устаревшие сообщения из локального файла (это настраивает администратор сервера) и получаются заголовки новых. Далее, если пользователь выберет загрузку всех новых сообщений, то на его компьютере после отключения от сервера останется копия структуры сообщений и сами сообщения, полностью соответствующая структуре на стороне сервера. Однако он может отметить, опять же, в офф-лайне, только заинтересовавшие сообщения и загрузить только их. Web-based конференции же рассчитаны на легкомысленного пользователя, тыкающего в приглянувшиеся заголовки, при этом сервер с каждым тыканием высылает целю кучу хлама (web.referent.ru не исключение), так как древовидная структура конференции эмулируется HTML (сейчас и DHTML), чтобы в браузере было видно подобие ньюсгруппы. И основная масса байтов каждый раз описывает однe и тe же структуру, с каждым новым сообщением заново строится в браузере псевдоньюсридер, в массиве HTML кода которого редкими вкраплениями содержится полезная информация.

Основным способом снижения нагрузки на сервер и экономии времени пользователя он-лайн является разделение структуры и полезной информации. Например, используя отдельный файл .css, структура, скажем, книги, может храниться в этом единственный раз переданном файле. А каждую новую 1001-ую страницу сервер высылает лишь размеченным короткими тэгами, и основная масса байт -- полезные, практически текст, который виден на экране. Следующим примером может служить data-binding. Используют его фирмы, регулярно обновляющие табличные прайсы. Сервер передает клиенту страницу, на которой описана таблица, а смена таблиц осуществляется не высылкой очередной заполненной таблицы (где хорошо, если 50/50 полезной информации), а указанием на текстовый файл, где, хранятся все столбцы и строки -- например, пробелами отделены столбцы, а строки и есть строки. Далее происходит этот самый "биндинг", где браузер, к тому же в офф-лайн, командами, например, DHTML, "заливает" в красивую таблицу (я видел с автоматическим подсчетом дисконта в зависимости от набранной корзины и калькулируемые) новые слова/цифры из этого компактного файла, не обращаясь больше к серверу. Разгружается сервер, экономится время в сети. Наконец, обобщением всех способов является XML. А вот на основе XML и его стайлшитов можно построить основанный на браузере почти полноценный ньюсридер. Вся структура пишется один раз, а потом используется наследование-ветвление. В результате того, что в XML можно задать какие угодно, свои, аттрибуты для данных, появляется возможность манипулировать ими, т.е. та же сортировка, перестройка на лету структуры дерева, скрытие-проявление части данных (новый суповой набор :0) и т.д.

Итак, дело за малым. Владельцу сервера можно всего лишь наблюдать, и то, если есть такое желание, что там себе придумывает клиентская сторона. А клиентской стороне, чтобы симулировать работу по протоколу NNTP, нужно:
1. клиенту определить место хранения архива на локальном диске;
2. написать стартовый файл HTML, который откроет с сервера текущее состояние дерева сообщений, в нашем случае файл tree;
3. прочитать, что уже есть на локальном диске;
3а. соединиться с сервером, загрузить файл tree и отсоединиться;
4. сравнить полученное в п.3 со свежим деревом от сервера и сгенерировать на клиентской стороне страницу, где показать в дереве (цветом или чек-боксами) сообщения, отсутствующие на локальном диске;
5. клиент в браузере ставит галку (или просто кликает, а они меняют цвет/символ и т.п.) на тех сообщениях, которые хочет получить для чтения офф-лайн и жмет кнопку "получить";
6. соединиться с сервером, синхронизация, и отсоединиться;
7. вновь пункт 4;
8. Done.
Так как файл, сгенерированный в п.4 для проверки отсутствующих на локальном диске сообщений, правильно линкован с файлами на локальном диске, клиент имеет офф-лайн архив. Как часто он будет синхронизировать, зависит от его желания быть в курсе. Какие возможности будут у архива для поиска, сортировки, и т.д., зависит от того, что написано в файле из пункта 2. Еще более разгрузить сервер и сэкономить время в он-лайн клиенту можно, если появится возможность получать только тело сообщения, без куска дерева внизу. Я, например, все равно его отрезал для архива by.ru, так как это ненужный дубликат информации, занимающий в среднем 90% полученных байтов из самого сообщения.

Всё что я написал, можно реализовать на Jscript/VBscript, если у клиента W98/NT4/W2k.

PS: к Новику: а что за проблемы с "a'la explorer" для НетСцапа?

--
Андрей Куликов
От Novik
К And (25.04.2001 22:21:54)
Дата 27.04.2001 11:55:03

Re: В целом согласен.

Приветствую.

>Про NNTP.

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

>при этом сервер с каждым тыканием высылает целю кучу хлама (web.referent.ru не

Ну, не так все грустно. Данные (в отличие от NNTP, кстати) передаются в жатом виде. Если Ваш браузер это позволяет. (А у 90% людей - позволяет). Так что кто генерирует больший траффик - еще вопрос.

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

Этоо все очень хорошо, но имеет некоторый минус. Все эти фишки не работают нормально в старых браузерах, а в новых частенько работают по разному. Т.е. убирается основное преимущество web форума - демократичность. Кредо примерно таково: основная работа должна обеспечиваться самыми примитивными средствами, имеющимися у всех. JavaScript, DHTML и т.п. могу использоваться только как дополнительные фишки для повышения удобства.

>1. клиенту определить место хранения архива на локальном диске;
>2. написать стартовый файл HTML, который откроет с сервера текущее состояние дерева сообщений, в нашем случае файл tree;
>3. прочитать, что уже есть на локальном диске;
>3а. соединиться с сервером, загрузить файл tree и отсоединиться;
>4. сравнить полученное в п.3 со свежим деревом от сервера и сгенерировать на клиентской стороне страницу, где показать в дереве (цветом или чек-боксами) сообщения, отсутствующие на локальном диске;

Я может, не совсем Вас понял, но 90% того, что Вы тут написали, уже реализуется подсистемой кеширования браузера. Т.е. если Вы регулярно посещаете форум, то именно это и имеете.

>PS: к Новику: а что за проблемы с "a'la explorer" для НетСцапа?

NS (до версии 6 по крайней мере) не поддерживает динамический layout. Т.е., к примеру, если Вы запахнете все ветки, то вертикальный скролбар никак не поменяется. Просто будет куча пустого пространства. Что губит на корню саму идею.
От And
К Novik (27.04.2001 11:55:03)
Дата 29.04.2001 20:20:00

Re: В целом...

>Приветствую.

И я рад видеть. Работа этого форума лучше многих, он очень удобен. Так что мои предложения не столько критика, сколько варианты на "подумать".

>> Про NNTP.
>
>Основной недостаток, как уже писал, "недемократичность". Достаточно много людей, которые сносно управляются с браузером но слыхом не слыхивали о ньюсах.

Спорить не будем.

>> при этом сервер с каждым тыканием высылает целю кучу хлама (web.referent.ru не
>
>Ну, не так все грустно. Данные (в отличие от NNTP, кстати) передаются в жатом виде. Если Ваш браузер это позволяет. (А у 90% людей - позволяет). Так что кто генерирует больший траффик - еще вопрос.

То есть сервер высылает меньше байт по HTTP, чем клиент имеет размер принятого HTML файла? Где можно почитать о таком, для меня это новость?

> Все эти фишки не работают нормально в старых браузерах.

На многих сайтах дают выбор: "полный сервис" или "no images, no scripts, no tables, no frames", это выход, причем разделяющий потоки уже на стадии GET HTTP. Делят же по языкам, по кодировке и т.д.

> 90% того, что Вы тут написали, уже реализуется подсистемой кеширования браузера. Т.е. если Вы регулярно посещаете форум, то именно это и имеете.

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

Небольшие комментарии к моим пунктам.

>> 1. клиенту определить место хранения архива на локальном диске;

Пользователь понятия не имеет, где находится кэш IE. А даже если и найдет, то не найдет файлы, а даже если и найдет файлы, то они будут иметь неверные ссылки и неверные имена. Значит, если он, как я, например, бегает между работой и домом, то захватить с собой архив закаченного "бесплатно" на работе -- неразрешимая для обычного пользователя проблема. Формат данных должен быть переносимым.

>> 2. написать стартовый файл HTML, который откроет с сервера текущее состояние дерева сообщений, в нашем случае файл tree;

Стартовый HTML (файл на локальном диске), а не просто строка adress в браузере -- это для того, чтобы скрипт из этого стартового HTML видел объектную модель документа tree и мог динамически с ним работать.

>> 3. прочитать, что уже есть на локальном диске;

Здесь я не упомянул о некотором неудобстве: при попытке доступа из стартового HTML содержимого к локальному диску выскочит сообщение что-то типа "небезопасная операция, продолжать?" (security reason). Но это обходится, правда не в скрипте, а в настройках браузера.

>> 3а. соединиться с сервером, загрузить файл tree и отсоединиться;

>> 4. сравнить полученное в п.3 со свежим деревом от сервера и сгенерировать на клиентской стороне страницу, где показать в дереве (цветом или чек-боксами) сообщения, отсутствующие на локальном диске;

бывает, заглянешь через пару дней, а новых сообщений более 200, и если хочешь держать под рукой все, это сколько раз кликать нужно? Для убыстрения загрузки можно открывать сообщения в новых окнах. Через контекстное меню? И так все 200 раз... :0) Не все знают клавиатурное сокращение Alt+ShiftClick. Мой компьютер для верстки не заметит и 50 открытых окон IE, а вот у обычной машины, из моего опыта, они после 15-го перестают даже отрисовываться. Их нужно принудительно закрыть и обновить дерево (получить с сервера ок.300К) для того, чтобы видеть страницы visited, иначе просто не вспомнишь, какие уже открыл, какие -- нет. А на стартовой странице всё просто -- можно поставить чек-бокс, динамически отмечающий "все новые сообщения" в нити или на странице, а потом доверить закачку скрипту или специально для этого созданной программе. Например, ReGet.

>> а что за проблемы с "a'la explorer" для НетСцапа?

>NS (до версии 6 по крайней мере) не поддерживает динамический layout. Т.е., к примеру, если Вы запахнете все ветки, то вертикальный скролбар никак не поменяется. Просто будет куча пустого пространства. Что губит на корню саму идею.

Надо подумать. Браузер NS хуже чем IE отвечает рекомендациям w3c, это факт.

--

Удачи,
Андрей Куликов

PS:
Помните, как показывала Deja.com сообщения с цитируемыми вставками? Нечетное количество знаков ">" и следующую строку одним цветом, четное количество -- другим. Добавляло хорошую порцию логичности в присылаемом сообщении. Но даже если ничего не менять на форуме, и то хорошо.
Как там.... от добра добра не ищут, лучшее враг хорошего... :0)
От Novik
К And (29.04.2001 20:20:00)
Дата 03.05.2001 11:04:49

Re: 5 копеек.

Приветствую.

>То есть сервер высылает меньше байт по HTTP, чем клиент имеет размер принятого HTML файла? Где можно почитать о таком, для меня это новость?

RFC1945 и RFC2068 :)

Коротенько примерно так. Браузер сообщает серверу о том, какой контент он понимает в строке заголовка Accept-Encoding. Наиболее распространенным является qzip. (IE, правда, говорит, что понимает еще и deflate, но deflate у него какой-то левый). В этом случае сервер отсылает браузеру контент пожатый gzip и указывает в заголовке признак - Content-Encoding: gzip. Всех делов. Имеем сокращение трафика в среднем в полтора раза.

Про остальное - попозже. Если соберусь.
От And
К And (25.04.2001 22:21:54)
Дата 25.04.2001 22:38:38

Re: Errata

>(чего стоит только , при каждом сообщении, где [ххх] есть имя файла, и более логичная структура HTML, где по nextSibling or nextNode легко бежится по нити. Меня до сих пор мутит, как вспомню, что обещал вам архив 10тыс одним файлом и придется-таки мне доморочить HTML с by.ru).

Эта фраза непонятна, так как я использовал написание тега из числа тех, которые отгрызаются этим форумом :(

Читать следует так:
(чего стоят только теги «а name=ххх» , при каждом сообщении, где [ххх] есть имя файла, ...)

--
Андрей Куликов