CommFort

Наиболее оптимальным на мой взгляд является работа непосредственно с сообщениями на стороне сервера.
Наприме:
1)приходит письмо
2)анализируется как ботом так и сервером(в случае необходимости отсечки некоторых сообщений,мойжно также разрешать боту видеть сообщения с определенным идентификатором)
3)далее..сервер непосредственно ждет сигнала от бота, который должен передать команду к примеру: отослать без изменений,отослать измененное..при этом передается в качестве аргуменат модифицированнео сообщение.

что-то в таком духе.
ибо с отслеживанием сообщенйи на сервере,и их непосредственаня модификация на нем же..добавит ряд полезный возможностей.

mw писал(а):Наиболее оптимальным на мой взгляд является работа непосредственно с сообщениями на стороне сервера.
Наприме:
1)приходит письмо
2)анализируется как ботом так и сервером(в случае необходимости отсечки некоторых сообщений,мойжно также разрешать боту видеть сообщения с определенным идентификатором)
3)далее..сервер непосредственно ждет сигнала от бота, который должен передать команду к примеру: отослать без изменений,отослать измененное..при этом передается в качестве аргуменат модифицированнео сообщение.

что-то в таком духе.
ибо с отслеживанием сообщенйи на сервере,и их непосредственаня модификация на нем же..добавит ряд полезный возможностей.

Я предлагал подобное, даже расписал что именно надо сделать.
Проблема с вашей идеей в том, что если ботом считать то что было в версии 3.20 то подобная схема вызовет страшные тормоза, на серверах где больше 200 пользователей, кроме этого при такой схеме надо как-то разделять клиентов и ботов, а это не предусмотрено, кроме того немного не ясно как обрабатывать сообщения несколькими ботами. В 4.0 ботом должен быть виртуальный пользователь, который создаётся плагином на сервере.

realmagus писал(а):

mw писал(а):Наиболее оптимальным на мой взгляд является работа непосредственно с сообщениями на стороне сервера.
Наприме:
1)приходит письмо
2)анализируется как ботом так и сервером(в случае необходимости отсечки некоторых сообщений,мойжно также разрешать боту видеть сообщения с определенным идентификатором)
3)далее..сервер непосредственно ждет сигнала от бота, который должен передать команду к примеру: отослать без изменений,отослать измененное..при этом передается в качестве аргуменат модифицированнео сообщение.

что-то в таком духе.
ибо с отслеживанием сообщенйи на сервере,и их непосредственаня модификация на нем же..добавит ряд полезный возможностей.

Я предлагал подобное, даже расписал что именно надо сделать.
Проблема с вашей идеей в том, что если ботом считать то что было в версии 3.20 то подобная схема вызовет страшные тормоза, на серверах где больше 200 пользователей, кроме этого при такой схеме надо как-то разделять клиентов и ботов, а это не предусмотрено, кроме того немного не ясно как обрабатывать сообщения несколькими ботами. В 4.0 ботом должен быть виртуальный пользователь, который создаётся плагином на сервере.

ну есть как бы такая штука как именованные каналы..т.е. создается файлик..но не обычный...и открывается доступ...двунаправленный..можно однонаправленный...через этот канал два процесса могут обмениваться сообщениями между собой.

К примеру. система такая:
1) приходит сообщение.ему соответствует некоторый код.
3)анализируется..если попадает под разрешенные для редактирования ботом сообщения - то посылается боту. и перед командой о сообщении в конвейер вставляется условная команда,которая будет отодвигать этап выполнения команды сообщения,до тех пор.пока не выполнится некоторое условие,к примеру не получен ответ от бота,либо количество пропусков этапа выполнения больше некоторого значения.
если команда попадает под разряд команд,которые бот не может обрабатывать, то она просто помещается в конвейер. т.е. например приватные соощения бот не сможет отслеживать,они будут выполнятся как есть..а вот общий чат как раз сможет. И если бот посчитает что в сообщение для общего чата есть мат. то он заменяет команду условного выполнения и саму комануд сообщения(а она у нас висит после условной команды)на например команду забанить и помещает ее впереди очереди.

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

Думаю, что реализовать это на порядок сложнее, чем серверные плагины, я так понял что схема чем-то напоминает remoting в C#. Все же зависимость скорости обработки от пропускной способности канала обратнопропорциональна, а запускать на том же компе, что и сервер, было б не логично

добавлю еще несколько плюсов поддержки плагинов сервером с возможностью эмуляции пользователей

1. полноценная линковка серверов
2. возможность сделать ирк шлюз. То есть плагин который мог бы подключать клиентов Ирк и передавать все ихние события на сервер.
При этом отпадет куча просьб создать клиент под юних и мобайл версии.
Все кто захотят смогут юзать клиенты Ирк.
3. можно будет сделать чату веб интерфейс

И еще пара слов о поддержке плагинов клиентами.

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

realmagus писал(а):Думаю, что реализовать это на порядок сложнее, чем серверные плагины, я так понял что схема чем-то напоминает remoting в C#. Все же зависимость скорости обработки от пропускной способности канала обратнопропорциональна, а запускать на том же компе, что и сервер, было б не логично

Ну если в вычислительных системах работает то может и тут будет работать просто это какбы схема разрешения конфликта по данным..немного переделанная под текущие нужды (не зря же учил и зачет сдавал по предмету)
Само выполнение можно реализовать в виде очереди..к томуже..как я понимаю в чате она и так должна быть.
Можно сделать что-то вроде конфигурации чата для обмена с ботом..к примеру бот сообщает чату какие сообщения ему необходимы и к примеру настройки производительности(ждать ли овтета от бота или выполнять сразу).Тем самым уменьшается время на передачу сообщений нафиг не сдавшихся боту. если есть паралельный поток который обрабатывает все сообщения..то будет наблюдатся некоторая параллельность выполнения (а если при этом будет и двухядерный процессор - то параллельность). И я думаю что если боты которые получали сообщения через сокеты работали нормально.. а работали они медленнее чем бот,работающий с файловой системой. то эта реализация вполне может иметь нормальную производительность. И мы ведь не блокиурем весь конвейер из-за одной команды...а лишь отодвигаем ее время выполнения. можно конешно реализовать и без задержки команды. а просто отсылать боту дубликат и не ждать ответа. а сообщеняи бота ставить сразу на выполнение.

А вобще..я вот прикинул и понял - оно того не стоит )
еслиб знать что именно необходимо в функционале системы - былоб проще )

Было бы неплохо оповещать бота о присоединении к серверу и отсоединении. Можно также при этих двух событиях сообщать IP и Порт сервера, к которому присоединились, либо отсоединились.

И ещё бы реализовать возможность просмотра информации о пользователе (где-то уже писалось не раз)...

Хотелось бы увидеть возможность не только наложения но и снятия ограничений (бан)
а так же возможность приглашения пользователя в канал

Хотелось бы чтобы все дополнения были на стороне сервера с возможностью пре-модерации(т.е. возможностью не публиковать или изменять сообщение). Но об этом уже говорили.

Прочел в соседней теме:

Поддержка программ-дополнений:
Поддерживаются программы-дополнения от версий 3.хх, но только в случае если не используются функции связанные с администрированием. Например, бот-викторина работать будет, а бот-антимат - нет.

Сразу возникло желание посмотреть на новый протокол. Выложили бы разработчики обновленный файл bots_inf или хотя бы изменения ....

Нет никакого нового протокола. Все также как было только без функций администрирования.

sVs писал(а):Нет никакого нового протокола. Все также как было только без функций администрирования.

Вот раз их нет, то это и есть новый протокол. Интересно узнать, каких именно функций не стало и какие новые появились.

Кот ДаWINчи писал(а):

sVs писал(а):Нет никакого нового протокола. Все также как было только без функций администрирования.

Вот раз их нет, то это и есть новый протокол. Интересно узнать, каких именно функций не стало и какие новые появились.

Никаких новых не слало, не работают все функции, которые требовали права админа включая приглашение в каналы. Будущее ботов, в нытче существующей реализации, туманно, скорее всего, клиентские боты будут упразнены в пользу серверных плагинов.