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