On Jul 13, 2009 at 22:26, Daniel-Constantin Mierla <miconda(a)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