On Jul 06, 2009 at 23:42, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; 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

On Jul 07, 2009 at 12:58, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote: They cannot map since xmlrpc has no support for attributes. I'm not sure what was the design goal of mi. If it was to enable full xmlrpc use it has failed (it uses xmlrpc in an extremely limited way and has some extra features that are not part of xmlrpc or any rpc I know). There are 2 ways of doing this using standard rpcs: either just list all the values ( 1234,10,"udp listener" ....) and rely on having a fixed number of records per process (that's what core.ps does), or use an array of structures, eg.: { pid = 1234 childid = 10 type = "UDP listener" } The advantage would be that this is a standard approach directly supported by xmlrpc (and other rpcs), so you don't need to deal with proprietary encodings (e.g. mi encoding over xmlrpc) and even the client code is much simpler. Does it mean that the xmlrpc reply is not sent immediately, but at a later point? Is it something used by seas? I mean making mi obsolete for any new stuff. The existing mi functions should/can be replaced but that is not a priority. If people using mi_xmlrpc can tell us what they expect (some packet dump will be nice), we can modify mi_rpc to produce exactly the expected format and so we could make mi_xmlrpc obsolete immediately. BTW: is it ok with you if I add more functions to mi_rpc? I want to have a version more compatible with ser RPCs (no attributes, only the value). Unfortunately it will still be limited to string only and no structs (since mi doesn't support them, it would be very hard to automatically guess the best type). Looking at the complex tree structures from mi, I thought mi_xmlrpc would do some very complex stuff. It turns out that is just a way of passing strings over xmlrpc (kind of the old fifo packed in xml, no xmlrpc feature is used). xmlrpc(s) uses also a library for doing the parsing. The difference is, it does not use a separate library for HTTP, it just reuses ser SIP-TCP transport for HTTP (that's why you can call a sr route for each XMLRPC request and do extra stuff like authentication, certificate verification a.s.o.). Andrei

Andrei Pelinescu-Onciul writes: there exists, for example, a click to dial app for k that sends invite as t_uac_dlg xmlrpc request and then analyzes the lines of the response: reply+reason request_uri next_hop routes_set other headers + body -- juha