On Jul 13, 2009 at 22:26, Daniel-Constantin Mierla miconda@gmail.com wrote:
[...]
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?
It should look the same as in kamailio, if you use mi_fifo or mi_udp commands in sercmd and use it in non-interactive mode. E.g.: sercmd -f "%v" mi_fifo pwd 200 OK WD:: /home/andrei/sr.git
If you don't add -f "%v" you'll see double '\n' (sercmd adds one at the end of each value by default).
In this mode sercmd can be used as a fifo or mi_datagram replacement (one will have to exec sercmd via a pipe instead of directly writing/reading from the fifo or datagram socket).
I've added mi_fifo, mi_dg, mi_xmlrpc and also slightly changed mi output (to have one function generating all of them). Now all of them output "lines" (each output value is a string containing one line). This was done to be compatible with mi_xmlrpc and to avoid code duplication. If the old mi output (with '+') is still "wanted" I can re-add it.
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
I was thinking of adding various mi_rpc commands. One would encoude node children to structs, another attributes to structs a.s.o. Unfortunately there's no clean solution, at least for the next release.
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.
Yes, I agree.
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.
I hope this is not a goal any longer (or if soap support is still desired at least it could be made to work based on normal rpc and without all the add-ons).
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.
I hoped the same, but a few greps through modules_k changed my mind :-)
Andrei