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

Andrei Pelinescu-Onciul andrei at iptel.org
Mon Jul 13 21:55:27 CEST 2009


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.

> 
> 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?
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 '=').
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