Здравствуйте Аноним, Вы писали:

А>OK, с меня спецификация интерфейса. Клиентская часть — RFC 977, TCP программирование. Никто, кстати, не знает NNTP сервера под виндами в сырцах? Нарезать из него и самим не заморачиваться.

А зачем TCP, можно ведь WinInet'ом обойтись.

А>И еще вопрос — таки http://sourceforge.net? Или держим проект на rsdn (а вообще есть желание и возможность)?

А что лучше?

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

IT>А зачем TCP, можно ведь WinInet'ом обойтись.

А на нем TCP запрограммить можно? :-O

А>>И еще вопрос — таки http://sourceforge.net? Или держим проект на rsdn (а вообще есть желание и возможность)?

IT>А что лучше?

Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

UC

Здравствуйте Аноним, Вы писали:

IT>>А зачем TCP, можно ведь WinInet'ом обойтись.

А> А на нем TCP запрограммить можно? :-O

На нём можно HTTP програмить.

IT>>А что лучше?

А> Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

Не, не знаю я никаких CVS, давай на sf.

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

IT>Здравствуйте Аноним, Вы писали:

IT>>>А зачем TCP, можно ведь WinInet'ом обойтись.

А>> А на нем TCP запрограммить можно? :-O

IT>На нём можно HTTP програмить.

IT>>>А что лучше?

А>> Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

IT>Не, не знаю я никаких CVS, давай на sf.

Значит, так:

Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

Первый вопрос такой: на каком языке естественно писать слой обработки данных? Чтоб по HTTP общался, разбирал (XML-ные?) ответы сервера и строки разрезал/склеивал/преобразовывал. Напрашивается VB (коряв, однако), Java (течет, однако, да и не знаю я ее толком) и C++ с развитой классовой структурой (закат солнца вручную, однако).

Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования? Идея такая, что данные (списки мессаджей) призодят пакованные в HTML, потом из надо бы распаковать во внутренне представление, гарантирующее соответсвие их формата стандарту (структурированные данные), а потом опять собрать в голый текст для передачи по TCP (там что-то очень похожее на интерфейс командной строки). Выбор идет между структурированными данными и неструктурированными, и какой-то комбинацией между ними.

Ну и надо уже думать о том, что будет канализированно в HTTP.
Нужны следующие команды (ответы на них):

1) LIST — список групп к информацией о группах,
2) GROUP — установка в качестве текущей данной группы с выдачей информации по ней.
3) ARTICLE, HEAD, BODY — отдача по номеру статьм в группе ее текста, заголовка, тела.
4) NEWNEWS — список msgid новых статей, с указанного момента.

Каждая статья должны быть снабжена уникальным msgid, статьи в группе должны быть пронумерованы.

На сорсефорже sourceforge.net проект я завел, называется rsdn2nntp. Он пустой пока.

ГС

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

GS>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

Давай C++, с #import там всё не немного сложнее васика.

GS>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

Я опишу возможности сервера, а ты уже смотри сам.
На сервере мы не можем запускать ничего кроме скриптов и стандартных COM-объектов. Писать свои расширения и COM-объекты мы не можем, но я и не вижу в этом особенной необходимости. Данные мы можем принимать в XML-формате, либо напрямую использовать существующую форму посылки сообщения. XML предпочтительнее, т.к. не придётся ничего менять, если изменится форма ввода нового сообщения. Отдавать данные можно тоже в XML'е или в любом другом формате, который будет удобней. Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

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

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

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

IT>Давай C++, с #import там всё не немного сложнее васика.

Дык дал уже, но продолжаю подозревать, что знал бы я лучше джаву...

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

IT>Я опишу возможности сервера, а ты уже смотри сам.

Ты отвечаешь на третий вопрос, а не на второй. Но это ничего.

IT> Данные мы можем принимать в XML-формате, либо напрямую использовать существующую форму посылки сообщения. XML предпочтительнее, т.к. не придётся ничего менять, если изменится форма ввода нового сообщения. Отдавать данные можно тоже в XML'е или в любом другом формате, который будет удобней.

ОК, поиграю с WinInetom и будут форматы.

IT>Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

ГС

Здравствуйте Аноним, Вы писали:

IT>>Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

А> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

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

IT>Здравствуйте Аноним, Вы писали:

А>> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

IT>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним ;)

Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

IT>Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.

Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.

ГС

Здравствуйте Аноним, Вы писали:

IT>>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним

А> Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

Бардак. Давай свой домашний e-mail, вышлю тебе твой пароль на него.

А> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.

Точно.

А> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

А> Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.

С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам. Что такое msgid, я не знаю, поясни, плиз. Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.

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

IT>Здравствуйте Аноним, Вы писали:

А>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

IT>Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

Казалось бы, вот этого хватает:

    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
    xmlhttp.Send xmldoc 
    Set resp = xmlhttp.responseXML

IT>С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам.

Т.е. в каждом форуме своя нумерация, но важно, что номера возрастают с возрастанием времени прихода сообщения на сервер. В принципе, может быть одна нумерация на все форумы, но я не уверен.

IT>Что такое msgid, я не знаю, поясни, плиз.

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

IT>Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.

Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

ГС

Здравствуйте Аноним, Вы писали:

А> Казалось бы, вот этого хватает:

Посмотрим.

А> Т.е. в каждом форуме своя нумерация, но важно, что номера возрастают с возрастанием времени прихода сообщения на сервер. В принципе, может быть одна нумерация на все форумы, но я не уверен.

Нет, нумерация сквозняком по всем форумам, т.е. одна на всех.

IT>>Что такое msgid, я не знаю, поясни, плиз.

А> Уникальный идентификатор. Идея такая, что номера статей на разных серверах могут быть разные, но айди для одной и той же статьи будет один и тот же. Обеспечивается тем, что вырабатывается клиентом и впоследствии переносится с сервера на сервер.

Ok. Надо будет делать для него поддержку, пока этого нет. Добавим.

А> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

Ты это погоди , пока постить ничего не надо. Тем более лучше сделать один скрипт, который будет принимать данные в XML формате.

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

IT>Нет, нумерация сквозняком по всем форумам, т.е. одна на всех.

ОК, давай пока так попробуем, не меняя.

А>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

IT>Ты это погоди :wow: , пока постить ничего не надо.

А что такое? Все равно при постинге проверяются креденшиалз, так что если кто захочет пошутить, то сделает это ограниченное число раз. Пролема в другом — я, тупенький, не понимаю, что происходит в 80-м порту, когда делается xmlhttp.Send xmldoc. Не понимаю я также, как из серверного ASP посмотреть что бы то ни было присланнное по xmlhttp.Send xmldoc.

IT>Тем более лучше сделать один скрипт, который будет принимать данные в XML формате.

Изложи идею поподробнее. Как посылать? Какой формат тебе посылать? На первом этапе должно хватать
1) команда — LIST
ответ — список имеющихся групп, с интервалами доступных номеров статей.
2) команда — GROUP <группа>
ответ — интервал статей
3) команда — ARTICLE <номер статьи>
ответ — статья

ГС

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

GS>Значит, так:

GS>Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

GS>Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

1. А почему первая уже сервис? Еще довольно много клиентов под Win9x осталось, как они этот сервис запустят?
2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

GS>Первый вопрос такой: на каком языке естественно писать слой обработки данных?
Однозначно С++. И можешь спокойно юзать XMLHTTP, а лучше ServerXMLHTTP — он надежнее, и вообще весь MSXML3.0 тебе понадобиться. Просто не на C++ этот пакет сильно раздует в размерах ;-)

GS>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?
Данные с сервера приходят в XML (формально), фактически они могут ити и в NNTP. Нам все равно в каком из текстовых протоколов посылать данные, главное чтоб по HTTP, а по HTTP можно передать что угодно. Например так:
<response>
215 list of newsgroups follows

rsdn.rsdn 6717 223 y
..........
.
</response>
Вообще можно на чистом NNTP: клиент передает NNTP через HTTP POST и получает NNTP ответ тоже по HTTP. На клиенте можно вообще убрать всякий разбор сообщений и т.п. Выбросить MSXML и юзать WinInet, тогда клиент будет совсем легким и скачивать его будет не напряжно.
Игорь, прочитай RFC 977 чтоб понимать о чем разговор.

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

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

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

IT>Давай C++, с #import там всё не немного сложнее васика.

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

IT>Я опишу возможности сервера, а ты уже смотри сам.
IT>На сервере мы не можем запускать ничего кроме скриптов и стандартных COM-объектов.
На самом деле мы можем писать свои расширения и CGI-exeшники, ASP, Perl, PHP, ColdFusion и др., короче полный комплект. А вот с КОМ-ом и фильтрами действительно туго.

Здравствуйте Аноним, Вы писали:

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

IT>>Здравствуйте Аноним, Вы писали:

А>>> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

IT>>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним ;)
Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?

А> Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

IT>>Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

А> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.
Тут не все так просто. NNTP работает на базе сессий, причем сессии эти реализованы удержанием соединения (ну что поделать, старенький это протокол). Тут есть два варианта обхода:
1. (предпочтительный) Работа с сессиями эмулируется на клиенте (проксе). Т.е. например на команды LAST и т.п. клиент ничего не посылает на сервер, а просто ставит себе на заметку. Все данные (включая имя и пароль) посылаются при запросе. Имя и пароль вводятся в настройках клиента.
2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом :-) )

А> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?
Лучше WinInet, так ты облегчишь клиента минимум на 600кб.

А> Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.
msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб :-)

Здравствуйте Аноним, Вы писали:

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

IT>>Здравствуйте Аноним, Вы писали:

А>>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

IT>>Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

А> Казалось бы, вот этого хватает:

А>

А>    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
А>    xmlhttp.Send xmldoc 
А>    Set resp = xmlhttp.responseXML
А>

:-(

IT>>С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам.

А> Т.е. в каждом форуме своя нумерация, но важно, что номера возрастают с возрастанием времени прихода сообщения на сервер. В принципе, может быть одна нумерация на все форумы, но я не уверен.

Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.

IT>>Что такое msgid, я не знаю, поясни, плиз.

А> Уникальный идентификатор. Идея такая, что номера статей на разных серверах могут быть разные, но айди для одной и той же статьи будет один и тот же. Обеспечивается тем, что вырабатывается клиентом и впоследствии переносится с сервера на сервер.

IT>>Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.
Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP).
2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream.
Схема такая:
Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу.
При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite.
Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?


А> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?
Сообщение в NNTP.
А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п? :wow:

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

GS>>Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

GS>>Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

S>1. А почему первая уже сервис? Еще довольно много клиентов под Win9x осталось, как они этот сервис запустят?

Как приложение, например.

S>2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

Если делать, как ты предлагаешь — весь разбор NNTP данных на сервере — то никаких сменных модулей не надо.

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?
S>Однозначно С++. И можешь спокойно юзать XMLHTTP, а лучше ServerXMLHTTP — он надежнее, и вообще весь MSXML3.0 тебе понадобиться. Просто не на C++ этот пакет сильно раздует в размерах

Принято.

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?
S>Данные с сервера приходят в XML (формально), фактически они могут ити и в NNTP. Нам все равно в каком из текстовых протоколов посылать данные, главное чтоб по HTTP, а по HTTP можно передать что угодно. Например так:
S><response>
S>215 list of newsgroups follows

S>rsdn.rsdn 6717 223 y
S>..........
S>.
S></response>
S>Вообще можно на чистом NNTP: клиент передает NNTP через HTTP POST и получает NNTP ответ тоже по HTTP. На клиенте можно вообще убрать всякий разбор сообщений и т.п. Выбросить MSXML и юзать WinInet, тогда клиент будет совсем легким и скачивать его будет не напряжно.


Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?

В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается.

А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки?


S>Игорь, прочитай RFC 977 чтоб понимать о чем разговор.

А также 2980 и 1036.

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

S>Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?

AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел.

А>> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.
S>Тут не все так просто. NNTP работает на базе сессий, причем сессии эти реализованы удержанием соединения (ну что поделать, старенький это протокол). Тут есть два варианта обхода:
S>1. (предпочтительный) Работа с сессиями эмулируется на клиенте (проксе). Т.е. например на команды LAST и т.п. клиент ничего не посылает на сервер, а просто ставит себе на заметку. Все данные (включая имя и пароль) посылаются при запросе. Имя и пароль вводятся в настройках клиента.

Т.е. протокол расширятеся на аутентификацию при каждом запросе.

S>2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом )

Т.е при каждом запросе на сервер он будет спрашивать куку? Тоже можно, но надо мне обхяснить, как с куками работать.

А>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?
S>Лучше WinInet, так ты облегчишь клиента минимум на 600кб.

Если мы доклеиваем к каждому NNTP сообщению сессионную информацию (логон, текушая группа, мессадж), то надо бы XML. Или нет?

S>msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб

Пока есть только чтение, можно считать, что msgid == номер.

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

S>Здравствуйте Аноним, Вы писали:

А>> Казалось бы, вот этого хватает:

А>>    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
А>>    xmlhttp.Send xmldoc 
А>>    Set resp = xmlhttp.responseXML

S>

Но как все-таки мерзко выглядит программирование XML-я на голых плюсах. Да и на ВБ не лучше.

S>Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.

Вот не нашел в стандарте такого, более того — должна же быть предусмотрена возможность для отработки cancel. Можно будет легко проверить — как OE реагирует на разрывы в последовательности.


S>Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP).
S>2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream.
S>Схема такая:
S>Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу.
S>При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite.
S>Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?


А>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?
S>Сообщение в NNTP.

Аутентификация? Текущая группа,номер?

S>А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п?

А ЮЮки на что?

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

S>>2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

GS> Если делать, как ты предлагаешь — весь разбор NNTP данных на сервере — то никаких сменных модулей не надо.
Просто я писал и по ходу дела додумывал :-)

GS>
GS>Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?
Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?), то на сервере это будет легче делать. А вот если нет, то ой...

GS>В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается.
Угу.

GS>А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки?
Request.Form
И поставь себе Visual InterDev или VS.NET, если хочешь ASP отлаживать.