JRuDevels

OCTAGRAM · Отметившийся

Зачем это нужно?
Потому что разные клиенты Jabber реализуют разные фичи. А также по–разному устроены. Вот те же транспорты от сервера не зависят, поэтому они так удобны, а на клиентской стороне такого нет. Пока. Если кому–то захочется реализовать дополнение для протокола (будь то игра в шашки или сетевой редактор а ля SubEthaEdit как дополнение к чату разработчиков на корпоративном сервере, или Jingle тот же) так, чтобы не привязываться к клиенту, то у такого разработчика нет средств для этого.

Я предлагаю как начальный вариант сделать посредника на localhost. А затем, когда клиент подключается (без SSL), решать вопрос с проксями, SSL и т. д. (заодно решится вопрос с клиентами, не поддерживающими SOCKS и HTTPS) и фильтровать XMPP. Часть XMPP пропускать без изменений клиенту, а часть передавать подключаемым плагинам.

Правда, остаётся открытым вопрос, как подключать плагины.

Во–первых, запуск по инициативе нашего каркаса и перенаправление ввода–вывода.
Во–вторых, слушать на том же порту, что и для клиента указан, дополнительные сервисы.

То есть, запустил что–то, это что–то подключилось к нашему посреднику, на том конце то же самое, и voila!

Проблема в том, что на серверной стороне не надо решать вопрос с портами, это задача администратора, а здесь надо. В многопользовательской среде может быть много пользователей с клиентами Jabber. А localhost — один на всех. Так что здесь два варианта (лучше оба) — каждый ставит посредника на свой порт (на Windows XP, правда, помимо 127.0.0.1 можно bind к любому адресу из 127/ Cool

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

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

leksey · Графоман

Как идея для "универсальных плагинов" это логичное решение.
Но так ли нужны эти плагины? И стоит ли все это ради шашек и пр.

feez · Разработчик

Похоже уже есть что-то подобное, если я правильно понял:
http://telepathy.freedesktop.org/wiki/FrontPage

OCTAGRAM · Отметившийся

leksey
Ну почему... мало ли там чего.
Даже без шашек найдутся XEPs, которые не везде реализованы, для каждого клиента–то отдельно реализовывать.
А так любой желающий смог бы написать реализацию, независимую от клиента.

Видеочат, например. Посылаешь в чат /video, посредник его перехватывает, запускается видеочат сразу с нужным человеком.

Или про сетевой редактор, что я говорил — передавать перемещения курсора и его действия через XMPP и получать от других — в дополнение к чату разработчиков.

Да мало ли чего может понадобится.

feez
Посмотрю...

Lion · Разработчик

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

OCTAGRAM · Отметившийся

Насчёт интерфейса — не думаю, основной смысл переиспользовать уже существующие каналы соединения. Как, например, это делает Timbuktu Pro.

coolkaas · Бывалый Жабовод

небольшая матчасть на примере нашеговсего:
со странички http://addons.miranda-im.org/details.php?action=viewfile&id=3282 по ссылочке Download вытягивается небольшой pdf-чик в архиве с общим названием Miranda IM Plugin Developer Guide 0.1.0.0 (англ.)

еще тематические ссылки: http://wiki.mirandaim.ru/wiki/SVN
в официальном транке есть папка sdk и папка testplugin

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

OCTAGRAM · Отметившийся

Здесь основная задача не один клиент с разными плагинами, а один плагин с разными клиентами.

То, что в Миранде, всё равно пригодится.

coolkaas · Бывалый Жабовод

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

Lion · Разработчик

OCTAGRAM · Отметившийся

coolkaas
Либо так, либо в каждый клиент отдельно подсистему писать. Можно оба варианта, постепенно ко второму варианту клиенты переделывать.

Проблема в том, что если кто захочет добавить функционал, возможностей для этого будет немного. Ну, допустим, напишешь свой функционал для Psi. А у чела Miranda. Или наоборот, напишет кто плагин для Miranda, а у чела Linux или, как у меня, Mac OS X, и ни в кой эта Миранда не встала.

Изначальный вариант пока самый трезвый.

Lion
Посредник может сообщить основному клиенту, что у объекта есть ad-hoc команда. А там дальше диалог можно передать и т. д.
Далее, перехватывать в чате команды, начинающиеся со слеша.

OCTAGRAM · Отметившийся

Вот, что я думаю :

С точки зрения плагинов, на порту посредника должен быть сервер Jabber. Плагин регистрируется на посреднике, генерирует пароль, посредник спрашивает пользователя про плагин, если да, регистрирует плагин как пользователя сервера и запоминает пароль. Дальше, с точки зрения плагина есть локальный транспорт, похожий на J2J. Во время его регистрации пересылается описание плагина. Потом через этот транспорт плагин видит всех пользователей в ростере. Это может пригодиться, если Jabber–плагин — сам плагин в какой–то программе, чтоб в этой программе можно было выбрать пользователя или группу и соединиться с ними.

Старался придумать решение, адекватное настоящей базе клиентского и серверного кода.