[sr-dev] mi vs RPC
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jul 7 12:58:44 CEST 2009
On 07/07/2009 12:40 AM, Andrei Pelinescu-Onciul wrote:
> On Jul 06, 2009 at 23:42, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> [...]
>
>> this has to be worked out more.
>>
>> The output is pre-formatted to be nicer displayed in sercmd, but
>> definitely cannot be used for xmlrpc transport. In K, mi tree can have
>> nodes with values and attributes. The attributes can have also values.
>> To be able to distinguish between nodes and attributes, I added +/-.
>> Also, some node names are missing, e.g., in 'which' command. A parameter
>> to control pretty formating along with mi command or a new command like
>> 'mi-pf' are options. Moreover, asynchronous mi command support is not
>> implemented.
>>
>
> What are attributes used for? I don't see them mapping to anything in
> terms of xmlrpc or standard rpc.
> Is anybody using the attributes?
>
there are some mi commands that set attributes in reply nodes, for
example ul_dump -- I discovered while implementing the mi_rpc.
As I am not a xmlrpc heavy user, I do not know if and how they map.
In mi, a node can have value and a set of attributes. Just for example
(does not mean it is so right now in the code):
<process pid="1234" childid="10">
UDP listener
</process>
> What's that asynchronous command support? How can one use it using xmlrpc
> (AFAIK xmlrpc does not support async. mode)? Is anybody using it?
>
This is used by some tm commands, for example: t_uac -- request is sent
in one process and reply could come back in another one. There are some
structures cloned in shm, filled on callback.
>
>> Personally I don't think is time to remove any of the modules, because
>> we may get trapped in some limitations of the other one. We should
>> follow the usual path, decide which is better, if can handle everything
>> the other does, mark the other obsolete for one release and remove after
>> another release cycle.
>>
>
> We shouldn't remove anything now, but after the next release I don't see
> any reason for keeping mi (other then maybe some legacy application that
> uses some obscure feature).
>
do you mean dropping MI the interface/library or the mi_xmlrpc? MI might
take longer, but mi_xmlrpc can be done in the next release.
I agree rpc in ser is easier to handle from developer point of view, the
concern I have in regard to xmlrpc(s) relates to the fact that is a
limited implementation, for what ser needed. Seems to be more that what
K needs in mi_xmlrpc, according to your review.
On the other hand, mi_xmlrpc uses a library from distro, which as aside
being developed for this purpose and probably follows more the specs,
proved to be buggy sometime.
So, I have no personal preference, mi_xmlrpc can be migrated anytime to
use the xmlrpc code from ser as long as it maintain the request/reply
format that has it in k 1.5.x, for the sake of migration easiness.
Cheers,
Daniel
> Correct me if I'm wrong (I did only a quick code read):
>
> mi_xmlrpc:
> - supports only strings as parameters
> - responses are either one big string (reply_option=0) or
> one array of string values (reply_option=1).
>
> For the first option (one big string) it kinds of defeats the purpose of
> XMLRPC. XMLRPC is an incredibly bloated and slow way of doing remote
> procedure calls, but at least is easy to use. You get the answer
> pre-parsed. However mi_rpc in one big string mode would require
> additional parsing of the big string to get individual values for any
> mi command returning a list (e.g. ps).
>
> For the second mode it always returns an array of string values, but this
> values look like: name:: value [attr_name=attr_value ...]. So again
> you'll have to do additional string parsing.
>
> - cannot return integers
> - cannot returns structures
>
> xmlrpc(s) doesn't have any of the above limitations.
> For example take core.tcp_info, an rpc that returns a structure with
> informations related to tcp:
>
> sercmd> core.tcp_info
> {
> readers: 8
> max_connections: 2048
> opened_connections: 0
> write_queued_bytes: 0
> }
>
>
> Using xmlrpc from perl I can access the opened_connections with the
> following piece of perl code:
>
> use XMLRPC::Lite;
> my $res=XMLRPC::Lite ->proxy("http://127.0.0.1:5060")->call("core.tcp_info")
> ->result;
> my %tcp_info=%{$res};
> print "opened connections: $tcp_info{opened_connections}\n";
>
> No extra parsing needed (try doing the same with a mi command).
>
>
> In general to me MI looks too complex. It seems is more complex and more
> annoying to write then ser RPCs and does less...
> RPC are easier to write, map perfectly on xmlrpc, support more types
> then just plain strings and have integrated docs (try
> sercmd help <rpc_command> or sending system.methodHelp <rpc_command> over
> xmlrpc).
>
> Example:
> The core.version rpc: (1 line of effective code)
> static void core_version(rpc_t* rpc, void* c)
> {
> rpc->add(c, "s", SERVER_HDR " " REPO_VER );
> }
>
>
> versus mi_version (modules_k/kex line 121): (28 lines of code excluding
> whitelines and defines, could be reduced to 20)
> static struct mi_root *mi_version(struct mi_root *cmd, void *param)
> {
> struct mi_root *rpl_tree;
> struct mi_node *rpl;
> struct mi_node *node;
>
> rpl_tree = init_mi_tree( 200, MI_SSTR(MI_OK));
> if (rpl_tree==0)
> return 0;
> rpl = &rpl_tree->node;
>
> node = add_mi_node_child( rpl, 0, MI_SSTR("Server"), SERVER_HDR+8,
> SERVER_HDR_LEN-8);
> if (node==0)
> goto error;
>
> node = add_mi_node_child( rpl, 0, MI_SSTR("Build"), BUILD_STR,
> BUILD_STR_LEN);
> if (node==0)
> goto error;
>
> #ifndef KAMAILIO_COMPILE_FLAGS
> #define KAMAILIO_COMPILE_FLAGS SER_COMPILE_FLAGS
> #endif
>
> node = add_mi_node_child( rpl, 0, MI_SSTR("Flags"), KAMAILIO_COMPILE_FLAGS,
> sizeof(KAMAILIO_COMPILE_FLAGS)-1);
> if (node==0)
> goto error;
>
> node = add_mi_node_child( rpl, 0, MI_SSTR("SVN"), SVNREVISION,
> sizeof(SVNREVISION)-1);
> if (node==0)
> goto error;
>
>
>
> return rpl_tree;
> error:
> LM_ERR("failed to add node\n");
> free_mi_tree(rpl_tree);
> return 0;
>
> }
>
>
>
>> I am more cautious to the changes done to things that interfaces with
>> the configuration file and mi/rpc transports, as these will break
>> installations and custom tools done by users, making migration nightmare.
>>
>
> I guess we have to find out how many custom tools there are out there that
> also process the responses of the mi commands (more then checking if the
> command succeeded or not).
>
>
> Andrei
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com/
More information about the sr-dev
mailing list