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" для НетСцапа?
--
Андрей Куликов
