[sr-dev] RPC WEB interface

[Daniel-Constantin Mierla]

Hello,

On 11/2/11 7:23 PM, Ovidiu Sas wrote:
> Hello all,
>
>
> I plan to build a small embedded web interface into sip-router for
> executing RPC commands from a web page.
> I already have part of the infrastructure working (re-using the HTTP
> part from core and the xhttp module).
> I would like to provide a simple and clean interface, organizing the
> access to RPC comands based on the module that provides them.
> The issue is that once an RPC command is registered into the core, the
> module that provides the command is not available.
> I'm looking foe a way to capture this information.  One way to capture
> this information would be to change the signature of the
> rpc_lookup.h:rpc_register_array() and provide the module name along
> with the  rpc_exports.  I know that some modules set the name of their
> rpc commands based on the following pattern:<module>.<rpc_command>,
> but his is not fully enforced (there are rpc commands that are not
> following this pattern).  One option would be to change the name of
> those commands and provide the old names as an alias.
> Also, there are modules that register the rpc_exports via the sr
> interface before the modules init and modules that registers the
> rpc_exports during init (via the rpc_register_array).
> This means that the list of rpc commands is not complete until all
> modules are initialized.  It would be good to be more strict and
> enforce rpc registration for all modules before init (this will
> require a new interface and I think there was a plan to merge the ser
> module interface with the kamailio module interface).
>
> To summarize, I'm trying to solve two issues here:
>   1. trace back the module that provides an rpc command based on command name;
>   2. enforcing a common module interface for both ser and kamailio modules.
it there would be a way of not changing the current signature of the 
function for registering rpc commands, I would prefer it. But cannot say 
it, since I haven't analyze the situation.

Regarding the second point, it will get to a new interface, but may take 
lot of time, there are lot of modules, it is not an easy task. But, no 
matter there is going to be a rpc commands structure in modules exports 
interface, there may be cases when one would like to register (extra) 
rpc commands in mod init, based on module parameters.

However, since 3.0, the child_init function is executed first for main 
process after all mod init functions were finished, with a special rank 
PROC_INIT -- then the forking happens and child init is executed again 
for main process with PROC_MAIN and for the rest of forked processes 
with appropriate rank parameter. Perhaps you can use this one to build 
your list with all rpc commands available in the instance.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda