Несколько новостей, связанных с CommuniGate Pro. Идея написать это родилась по итогам чтения текста об изменениях в последней доступной публично бета-версии - 5.1c4.
Во-первых, то, о чем мы уже давно рассказываем на семинарах, случилось - в состав CGP включена бета-версия веб-интерфейса (скина), сделанная на Flash! Да, нужен последний Flash 9, нужно поставить версию 5.1c4, заходим на http://server:8100/Pronto и видим это счастье. Те, кто не поленится это сделать, поймут, что это, конечно, совсем-совсем бета. Однако, понять идеи разработчиков уже более чем можно - пожалуйста!
Главная идея в том, что на самом деле плохо жить без собственной программы-клиента. Вернее, пока CGatePro "умел" только почту - можно было. Потом появились Groupware-возможности и стало сложнее - пришлось "подстраиваться" под Outlook с его протоколом MAPI, что было сложно, но получилось. С голосом, который давно уже является основным mainstream, без своего клиента еще сложнее. Правда, пока я вижу в том, что выкатили только IM, да и то в довольно зачаточном состоянии, но все же... Сам файл pronto.swf занимает сейчас 575Кб. Он, я так понимаю, кэшируется (?) в браузере у клиента.
Почему Flash. Клиент должен быть многоплатформенным. Соответственно, писать его под каждую платформу нереально и вообще XXI век... Flash - это уже практически обычный язык программирования, на котором можно писать вполне себе полноценные программы. Кроме того, есть реализация практически под любую клиентскую операционную систему. Плюс ко всему...
Работает с сервером он не по всем этим бессчетным протоколам доступа (IMAP, SMTP, SIP, XMPP, MAPI,...) а по (вот тут главное новое слово) протоколу XIMSS - собственному XML API к серверу. Новый протокол. Собственный протокол. Протокол, на который нет общепризнанного стандарта (RFC, например). Зачем? Ведь долгое время мы говорим, что работаем только по протоколам, имеющим открытые стандарты.
Вот моё объяснение. Много лет, практически как только я начал работать с интернетом, я знаю, что "интернет плохой". То есть, в нем все неидеально и все не так как нужно. Если бы те стандартные протоколы, которыми мы каждый день [незримо] пользуемся, создавались сейчас, а не тогда, когда они на самом деле были созданы, все было бы сильно лучше - к текущему моменту мир накопил столько претензий к тому, как создан интернет, что если бы их сейчас учесть и все переделать, все было бы совсем по-другому. Сегодня смотрел "Назад в будущее". Эх, так вот, поехал и поправил что-нибудь в прошлом, не получится. Однако, это не значит, что нужно бесконечно подстраиваться под существующую "неправильную" реальность. Нужно делать свою, лучше. Благо, иногда такая возможность имеется.
Если вы посмотрите на текущие возможности XIMSS, вы увидите, что протокол содержит методы для операций с сообщениями, ящиками, контактами, календарями, IM, а также для работы с сигнализацией, звонками, roster и presense и так далее. На примере (ищите ниже по тексту ссылки текст "The Client forwards the message 156 stored in the INBOX folder to the a1@domain address") операции пересылки (forward) почтового сообщения можно хорошо проиллюстрировать идеологию: есть объекты на сервере, с которыми клиент может работать используя XML API.
Например, вставить в текст письма уже имеющееся на сервере письмо не скачивая его. То есть, для выполнения forward не нужно загружать письмо клиенту - можно сделать все прямо на сервере. Есть "умный" сервер, которое многое умеет, есть "глупый" клиент, который знает как выполнять серверные операции - это применимо ко всему-всему. В итоге, клиент получается очень простым, а вся логика на сервере. Это дает возможность удешевить клиента.
То есть, не нужно умных клиентов - умный у нас уже есть, это сервер. Соответственно, клиент получается очень дешевый, так как не умеет думать, а может просто отображать то, что происходит на сервере. Это относится как к тому же Pronto-клиенту на Flash, так и к IP-телефонам, которым для того, чтобы работать с таким сервером, нужно почитать подробнее на эту тему можно тут и тут. Идея красивая: "Всё, что нужно от этой мыльницы с портом, это иметь примитивный XML-парсер - и ФСЁ". Вероятно, на XIMSS будет RFC.
На самом деле текст про XIMSS должен быть побольше и поподробнее, но не тут и не сейчас уж :) А пока далее про новинки. Те, кто следит за бета-версиями знают, что уже все лето мы поддерживаем протокол XMPP (Jabber) для подключения клиентов к серверу. Пока это только messaging. То есть, можно взять свой любимый XMPP-клиент Miranda, Trillian, iChat или еще какой-нибудь (хороший список есть у Google) и работать с CGatePro из него. Пока неясно с голосом и пока нет S2S.
В XMPP есть такое понятие как roster (buddy list) - список контактов с дополнительной информацией (например, настоящее имя пользователя или его nickname), хранимый на сервере. Ростер уже давно есть в CGP и сейчас он развивается - имена, введенные контактам через веб-ростер, теперь видны также в том же Windows Messenger (см. картинку).
Насколько мне известно, это далось серьезной кровью. Дело в том, что Microsoft хоть и делает ставку на SIP, использует множество нестандартных расширений этого протокола, которые не документируются, что серьезно усложняет дело. Я не знаю, какое количество новых "усовершенствований" SIP будет в Exchange 2007 и LCS, но что их будет много и работать с ними сторонним SIP-клиентам и серверам будет сложно - это практически без сомнений.
Еще одна интересная фича: фукнция StoreCDR в языке для создания голосовых приложений CG/PL. SIP для операторов часто является не очень удобным протоколом, так как его идеология не всегда кореллирует с устоявшейся практикой. Например, операторы привыкли, что когда состоялся телефонный разговор, в их биллинг попадает сооветствующая запись об этом - CDR (call detail record). В случае SIP конец разговора - это пакет BYE от SIP-клиента (если звонок прекращен по инициативе пользователя). Однако, если, например, соединение не завершилось таким пакетом (например, у клиента "кончился" интернет), то не ясно, когда закончилась сессия и что делать.
Решением является, например, пропуск звонка через "думающее" PBX-приложение, которое обладает определенной логикой, которая может отработать такую ситуацию, а затем отправить в биллинг "правильный" CDR. StoreCDR как раз отдаст процессору CDR правильную запись.
Ну, как-то так вот, примерно - это то, что я хотел рассказать о новшествах в CommuniGate Pro версии 5.1c4, появившейся 12 сентября :) Надеюсь, "нетехническим" читателям блога не было скучно.