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