Re: CG/PL<->XIMSS App Connection

От: Alexey Naidyonov <CGatePro_at_mx_ru>
Дата: Wed 18 Oct 2006 - 15:31:30 MSD

On Wed, 2006-10-18 at 03:40 -0700, Vladimir A. Butenko wrote:

Добрый день.

> <taskFindMeeting id="dd" meeting="" password="conference" />

> S:<taskMeeting meeting="" password="conference" taskRef="1"
> Expires="20061025T100543"><emptySet/></taskMeeting>
> S:<response id="ss" />

<emptySet/> -- это, видимо, default meeting set? А что там будет в случае named meeting set?

> Тут вот taskRef - это ссылка на таск. Ваша XIMSS сессия внутри хранит
> реальные ссылки (они могут быть на другие члены кластера), а вам выдает
> простые токены-ссылки (сейчас это вообще просто номера).
> По этим номерам Вы можете что-то в таск послать:
> C: <taskSendEvent id="sss" taskRef="1" eventName="getQQ"
> >data-string</taskSendEvent>|

Да, хорошо.

> Так как таски видят Вас (Вашу XIMSS сессию) как тоже таск, они могут
> ответить, что conferencehost.sppr и делает, отсылая взад список участников
> конференции. Он тут пустой:
> S: <taskEvent taskRef="1" eventName="partyList">{}</taskEvent>
> То есть приходит мессаж от сервера <taskEvent> - в нем есть "от кого" -
> опять же taskRef (если сервер сам послал - то не будет, taskRef, но пока
> сервер сам ничего не посылает), имя события, и тело XML - содержимое
> события.

Отлично!

> Аналогично можно будет добраться до тасков в Queue.
> Будет еще, видимо, возможность создавать таски из <XIMSS ..>

Да, возможность создавать задачи из XIMSS необходима. Например, чтобы запустить конференцию с автодозвоном до участников.

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

В принципе, мы себе хорошо уже сделали :) Правда, с помощью специального прокси-сервера. С одной стороны он принимает запросы от клиентского JavaScript и посылает ответы. С другой стороны, он шлет запросы в CG/PL (через CLI StartPBXTask), и получает ответы от CG/PL (HTTPCall на специальный URL). По семантике получается очень похоже на то, что описано. Между прокси-сервером и JavaScript ходят CGPшные словарики, которые JS сериализует-десериализует в JS объекты (благо, CGPшные словарики изоморфны JSON).
В принципе, можно даже посмотреть: если зайти на http://pbxdemo.itoolabs.com:8889/page.html и позвонить на sip:democonference@pbxdemo.itoolabs.com, то можно себя замьютить или даже кикнуть, чистый JavaScript, все без задержек и рефрешей страниц.

Чтобы перейти на XIMSS нам для полного счастья очень теперь нужен XIMSS/HTTP Binding. Это похоже на XMPP HTTP Binding -- клиенту при логине выдается session id, и если клиент с этим session id сделает GET на специальный URL, то он будет там висеть, пока не случится какой-нибудь таймаут (в некоторых браузерах случается), либо пока сервер ему на этот GET не ответит каким-то пришедшим для этого клиента событием. Тогда клиент это событие обрабатывает и приходит на тот же URL за следующим. Получается не то, чтобы поллинг (потому что ресурсов ест гораздо меньше), и, в общем, дает минимальную задержку при передаче события.
Запросы же клиент передает посредством POST на другой специальный URL. В случае XIMSS ответы сервера лучше оборачивать в какой-нибудь <response>...</response>, потому что CGP может вернуть подряд несколько элементов (e.g., <folderReport>), а если у полученного через XMLHTTPRequest документа будет несколько рутовых элементов, то JS расстроится.

Наш прокси HTTP Binding поддерживает, но как только в CGP будет XIMSS/HTTP Binding, то мы с радостью перейдем на него. Меньше бинарников -- меньше боли. Вопрос, насколько это сложно, возможно ли вообще, и как скоро можно было бы увидеть в CGP. Спасибо.

С уважением,
--
 Alexey Naidyonov
 ITooLabs Получено Wed Oct 18 11:31:55 2006

Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:15:09 MSK