[sr-dev] [Kamailio-Users] new module: mi_rpc

Daniel-Constantin Mierla miconda at gmail.com
Mon Jul 13 22:26:47 CEST 2009



On 13.07.2009 21:55 Uhr, Andrei Pelinescu-Onciul wrote:
> On Jul 13, 2009 at 20:57, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>   
>> On 13.07.2009 19:51 Uhr, Juha Heinanen wrote:
>>     
>>> Daniel-Constantin Mierla writes:
>>>
>>>       
> [...]
>   
>>> would it be possible to get the result in same (preferable the former)
>>> format in both cases? 
>>>  
>>>       
>> you can try implementing a new command in the mi_rpc modulem say 'mix' 
>> (mi for xmlrpc) that will format the output as you want.
>>     
>
> It's possible to have full mi_xmlrpc , xmlrpc+mi output compatibility
> (meaning identical output). I'm working on it right now.
>   

How will this look over fifo or udp?

I hoped to get with mi_rpc output in the native RPC format. AFAIK, there 
are "member" elements in the structure that can have name and value. 
That maps to mi node name and value. Attributes are something that maybe 
can be encoded in the value

Next would have been a MI "rpc" command to be able to execute rpc 
commands via MI, with output in MI format. However, this is more complex 
and probably makes no sense.

If you try to get name, value and attributes in one string and return 
the array of them, it is useless for those having ser xmlrpc parsers and 
inconsistent across the ser rpc commands reply.


>> However would be good to get a single command, but I do not know if is 
>> possible considering that MI reply trees have:
>> - name for nodes
>> - values for nodes - string or other nodes
>> - attributes for nodes - string
>>     
>
> mi_xmlrpc transforms all that values in a string and then adds it to the
> xml reply. So the xmlrpc result will be an array of strings, each string
> containing a node name, value and attributes list (similar output to
> mi_fifo and mi_datagram only encapsulated in xmlrpc, one string
> corresponding to each mi_fifo line).
>
> So all that extra stuff is for nothing, all the mi_* modules transform
> it to a simple string in the following format:
>
> <node name>:: <node value>[ <attr name>=<attr value>...]
>
>
> What I profoundly dislike in mi is this completely useless and overly
> complex tree structure. I understood that it was made this way to map on
> a xml document, but the questions remains why?
>   

Next transport was planned among firsts - soap - but no devel resources 
for it.

> The only link between xmlrpc and pure xml is the _transport_. xmlrpc
> encapsulates rpc in xml, you don't need to build xml documents by hand.
> xmlrpc is quite simple, it has a limited number of basic types (int,
> string, float, array and struct) and a very simple format: each function
> call is represented by a method name and a list of parameters and each
> answer by a _single_ value or a fault. There are _no_ named values and
> no attributes. Structures have named members, but that's about it.
>
> So all this extra "features" from mi cannot be used in a consistent way
> (you would have to write your own parsers for the mi_* output and even
> then is not clear how one would deal with values containing spaces in
> them, or even worse spaces and '=').
>   

This I hoped to fix with mi_rpc - the output of the mi command to be 
XMLRPC properly formatted.

Cheers,
Daniel

> What's even worse is that kamailio modules do not use mi in the same
> way. Some add attributes, other prefer adding named child nodes a.s.o.
>
>   
>> IIRC, Andrei proposed to put the value of the attributes in the value of 
>> the node. Now, the formating looks a bit strange, as  I did it to 
>> regocnize the above elements, so:
>> + means that the printed line corresponds to a node
>> - means that the printed line corresponds to an attribute of the last 
>> printed node
>>     
>
> I'll try to add some limited translation mode to ser rpcs. Unfortunately
> due to the inconsistent mi use by the k modules, it won't work for all
> of them (sometimes attributes would need to map to structures, other times
> node children would need to be structures). There is also the type
> problem: mi knows only about strings so an optimised mapping would not
> be possible.
>
>
>   
>> Within a node line:
>> - what is before '::' is the name of node
>> - what is after '::' is the value of node
>> - tab indentation is used to show the depth of nodes and attributes
>>
>> All these are taken from mi_fifo.
>>
>> So, in case of statistics, the nodes have no name and the value has the 
>> format "stat = value". I can say it is pretty weird, but it is the 
>> current style with mi_fifo. As I am not a xmlrpc user, with mi_datagram 
>> I did text parsing.
>>     
>
> The differences from mi_xmlrpc are minimal: mi_xmlrpc  doesn't print the 
> tree code at the begining (e.g. "200 Ok\n") and it doesn't add an extra
> "\n" at the end of the message.
>
>
> Andrei
>   



More information about the sr-dev mailing list