Re: [sr-dev] mi vs RPC

On Jul 06, 2009 at 23:42, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: [...] 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?

What's that asynchronous command support? How can one use it using xmlrpc (AFAIK xmlrpc does not support async. mode)? Is anybody using it?

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).

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 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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev