Re: CGP п╨п╟п╨ п╬я└п╦я│п╫п╟я▐ п░п╒п║ - ???

От: Alexey Naidyonov <CGatePro_at_mx_ru>
Дата: Wed 02 Aug 2006 - 15:56:37 MSD

On Wed, 2006-08-02 at 04:09 -0700, Vladimir A. Butenko wrote:

Добрый день.

> Но, в отличие от Микрософта, у нас протокол для написания таких клиентов -
> открытый

Насколько открытый? Есть ли какой-нибудь список рассылки, например, где обсуждаются планы развития XIMSS? Можно ли присылать свои замечания и предложения, как по новшествам, так и по семантике уже реализованного?

А то у меня таких много, вот, например:

Сейчас взаимодействие внешнего приложения (назовем его, чтобы не уходить далеко от темы, "АРМ оператора учрежденческой АТС") с задачей на CG/PL приходится делать либо через поллинг значений в settings (что, по некоторым причинам, неприемлимо), либо очень сложно, комбинацией управления сигналами CLI и механизмом работы с IM XIMSS: внешняя программа подключается к CGP с помощью XIMSS и CLI, запускает специальную задачу и дальше передает сообщения через CLI, и получает сообщения через XIMSS: var Task = cliConn.startPBXTask("webpanelconn", "Main", sessId); ...
> ximssConn.onpacketreceived["readIM"] = function(packet) {

      try {
        var data = CGPDict.cgpToJS(getPacketBody(packet));
        if (data != null && data.sessId == sessId) {
           ...
           if (data.cmd == 'requestvoice') {
              Panel.setBlinking(data.user);
           } else ...
        }
      } catch (e) {
        Logger.log("Error processing incoming packet: "+e);
      }

  }
...
  ConfUser.prototype.giveVoice = function() {

      var data = new Object();
      data.cmd = 'givevoice';
      data.user = this.userId;
      data.sessId = sessId;
>      Task.sendEvent(data.cmd, CGPDict.JStoCgp(data));

  }

В CG/PL задаче вызывается SendInstantMessage с сериализованным в строку CGP словарем. Это решение нам не нравится по ряду причин:

1. Оно требует сразу двух подключений, XIMSS и CLI. 2. IM оперирует с пользователями и не позволяет адресовать конкретное подключение. Таким образом, если под одним аккаунтом будет работать несколько внешних программ, то понадобятся специальные усилия, чтобы выделять сообщения, адресованные конкретной программе. Причем, для таких внешних программ придется выделять специальный account, иначе обычному пользователю с Windows Messenger будут сыпаться непонятные ему сообщения с cgp словарями.
3. Это решение некрасиво.

Нам очень хотелось бы увидеть в XIMSS полноценный двусторонний механизм обмена сообщениями между внешними приложениями и CG/PL задачами.

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

1. Ввести возможность адресовать IM не просто конкретному эккаунту, а конкретному подключению этого эккаунта. Такая возможность отсутствует в стандарте SIP, но она есть, например, в XMPP, поэтому, возможно, её придется так или иначе реализовывать (очевидный способ -- параметризовать SIP URI, например вот так: sip:growler@itoolabs.com;branch=home0123456) В дополнение к этому, добавить в CG/PL возможность получить с помощью ReadInput() пришедшее на адрес задачи IM сообщение.

Это бы решило нашу проблемы -- мы бы смогли посылать сообщения из CG/PL конкретному приложению, подключенному с помощью XIMSS, и наоборот. 2. Ввести понятие "внешней задачи" -- расширить XIMSS командой, по которой на сервере (узле кластера) создавался бы для этого подключения некий task stub, включенный в инфраструктур обмена сообщениями между CG/PL задачами. Расширить также XIMSS элементами: spawn, посылается клиентом серверу, стартует CG/PL задачу <spawn name="name" entry="entry">
  <parameter>....</>
</>

spawn, посылается сервером клиенту, возвращает taskRef CG/PL задачи <spawn taskRef="..."/>

sendEvent посылается клиентом серверу, передает сообщение <sendEvent taskRef="..." name="...">
  <parameter>...</>
</>

readEvent, посылается сервером клиенту, передает сообщение <readEvent taskRef="..." name="...">
  <parameter>...</>
</>

В принципе, этого достаточно, но для удобства можно вынести в XIMSS ещё несколько примитивов синхронизации, хотя бы createmeeting, activatemeeting, createqueue, enqueue.

В этом случае, с точки зрения CGP, это будет просто ещё одна задача (в каком-то неизменном состоянии), только выполняемая не на сервере (узле кластера), а где-то снаружи.

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

Владимир, прокомментируйте, пожалуйста, если не затруднит.

Спасибо.

С уважением,

-- 
 Alexey Naidyonov
 ITooLabs

Получено Wed Aug 02 11:56:43 2006