Re: CG/PL:обработка HTTPзапросов

On Tue, 07 Nov 2006 12:04:36 +0300
  "Alexey Naidyonov" <CGatePro@mx.ru> wrote:
> Владимир, добрый день.
>
> Возможно ли реализовать механизм для обработки HTTP запросов с помощью
> CG/PL программ? Например так:

Да, это планируется.

> 1. В настройках HTTP модуля добавляется настройка "CG/PL Applications":
>
> CG/PL Common URL Prefix: /cgpl
> CG/PL Account URL Prefix: /cgpl
>
> URL Task
> acd/queuestate acd.ajaxui.getqueuestate
> acd/queuecmd acd.ajaxui.issuequeuecmd
> ~/conf/userlist personalconference.ajaxui.getuserlist
> ...
>
> 2. При запросе на URL http://server/cgpl/acd/queuestate или
> http://server/~username/cgpl/conf/userlist запускается соответствующая
> задача, которая получает на вход словарь с запросом
> (Vars().httpRequest). Задача запускается в специальном режиме, функции,
> которые связаны с обработкой сигналов, будут возвращать ошибки, но при
> этом задача можно стартовать другие задачи и участвовать в обмене
> сообщениями и синхронизации.

Там не совсем так. Язык CG/PL =/= языку PBX. И описание PBX функций, как Вы видели - отдельное. То есть - есть ядро языка, а над ним - есть разные реализации (пока - просто разные наборы не-базовых функций, посовывамые и компилятору, и траснлятору).

Поэтому язык там будет CG/PL, но не PBX. И, скорее всего, в нем не будет spawn (потому что CGI процесс - это не задача, с которой можно обменяться сигналами). А может, и задача - если получится.   

> 3. В принципе, этот механизм нужен только для управления, понятно, что
> закачивать/скачивать файлы таким образом никто не будет, у CGP есть для
> этого более удобные механизмы. Поэтому можно ограничить размер входящего
> запроса, и отдавать тело запроса в виде строки из словаря
> (Vars().httpRequest.body).
>
> 4. Для выдачи информации обратно, тем не менее, хочется все-таки иметь
> возможность писать в поток, чанками.
>
> Зачем это нужно:
> - для решения задач управления приложением, когда мы не можем отдать
> XIMSS. Например, это внешний абонент, который принимает участие в
> конференции "нашего" абонента. Он авторизован (знанием пин-кода, который
> дал ему "наш" абонент), но давать ему доступ по XIMSS мы не можем. Опять
> же, это полностью решается внешним прокси (который к CGP уже может быть
> подключен по XIMSS), но хотелось бы обойтись без него.
Не совсем понятно, но здорово :-).

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

Опять же - есть очень большое желание выпихнуть Вас с сервера, всучив XIMSS вместо CG/PL. Если HTTP клиент - всё равно Ваш, то в чем, собственно, проблема - в том, что XIMSS требует локального аккаунта, пароль которого давать не хочется (это понятно), или в том, что XIMSS требует отдельных соединений (это должно решиться реализацией HTTP binding?) или чем-то еще?

> SY,
> --
> Alexey Naidyonov
> ITooLabs

Sincerely,
Vladimir Получено Tue Nov 07 09:41:55 2006