On 13.07.2009 19:51 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
here is what mi_rpc modules does:
- it receives a rpc handler form the rpc interface in core
- reads first parameter and then lookups MI command, if not found then
returns error, if found:
- reads all parameters as string and build internal MI tree
ok, after andrei fixed some bug, i got stats working via mi_rpc and xmlrpc module interface.
all stats except "tm:", which is now implemented using tm.stats command.
res = c.tm.stats()
provides this kind of result:
{'2xx': 0, 'created': 0, '5xx': 0, 'delayed_free': 0, 'current': 0, 'total_local': 0, 'waiting': 0, '6xx': 0, '4xx': 0, '3xx': 0, 'total': 0, 'replied_locally': 0, 'freed': 0}
whereas mi based stat results look like this:
['200 OK\n', '+ :: core:rcv_requests = 3', '+ :: core:rcv_replies = 0', '+ :: core:fwd_requests = 0', '+ :: core:fwd_replies = 0', '+ :: core:drop_requests = 0', '+ :: core:drop_replies = 0', '+ :: core:err_requests = 0', '+ :: core:err_replies = 0', '+ :: core:bad_URIs_rcvd = 0', '+ :: core:unsupported_methods = 3', '+ :: core:bad_msg_hdr = 0']
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.
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
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
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.
Cheers, Daniel
On Jul 13, 2009 at 20:57, Daniel-Constantin Mierla miconda@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
On 13.07.2009 21:55 Uhr, Andrei Pelinescu-Onciul wrote:
On Jul 13, 2009 at 20:57, Daniel-Constantin Mierla miconda@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
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
Daniel,
On 13-07 22:26, Daniel-Constantin Mierla wrote:
Next transport was planned among firsts - soap - but no devel resources for it.
Just out of curiosity, why? Do you have a usecase for it? I also considered that a long time ago, but then decided for XML-RPC instead, because it is lightweight and does everything that one needs to execute remote commands on the SIP server. SOAP is much more complex and involves a lot more processing (especially XML), but in the end it would not offer much more than XML-RPC.
Jan.
Hello,
On 14.07.2009 14:29 Uhr, Jan Janak wrote:
Daniel,
On 13-07 22:26, Daniel-Constantin Mierla wrote:
Next transport was planned among firsts - soap - but no devel resources for it.
Just out of curiosity, why?
seemed to be one of the most used protocols for provisioning, meanwhile priorities has changed and the demands for it were not really high.
Cheers, Daniel
Do you have a usecase for it? I also considered that a long time ago, but then decided for XML-RPC instead, because it is lightweight and does everything that one needs to execute remote commands on the SIP server. SOAP is much more complex and involves a lot more processing (especially XML), but in the end it would not offer much more than XML-RPC.
Jan.
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak