6 Jul
2009
6 Jul
'09
5:42 p.m.
On 07/06/2009 02:35 PM, Andrei Pelinescu-Onciul wrote:
On Jul 04, 2009 at 12:14, Juha Heinanen
<jh(a)tutpro.com> wrote:
this has to be worked out more.
The output is pre-formatted to be nicer displayed in sercmd, but
definitely cannot be used for xmlrpc transport. In K, mi tree can have
nodes with values and attributes. The attributes can have also values.
To be able to distinguish between nodes and attributes, I added +/-.
Also, some node names are missing, e.g., in 'which' command. A parameter
to control pretty formating along with mi command or a new command like
'mi-pf' are options. Moreover, asynchronous mi command support is not
implemented.
Personally I don't think is time to remove any of the modules, because
we may get trapped in some limitations of the other one. We should
follow the usual path, decide which is better, if can handle everything
the other does, mark the other obsolete for one release and remove after
another release cycle.
I am more cautious to the changes done to things that interfaces with
the configuration file and mi/rpc transports, as these will break
installations and custom tools done by users, making migration nightmare.
Cheers,
Daniel
in situation where both k and s modules are in
use, is there a need for
two different xmlrpc clients or can s or k xmlrpc interface be used to
issue all xmlrpc commands?
i have noticed that serctl has mi argument after which a k ctl command
can be given via ser ctl transport. does the same apply also to ser
xmlrpc transport?
Theoretically yes, but in practice there might be some change needed.
For example the mi_rpc module seems to include the reason
(e.g. 200 Ok) among the parameters and then it prints some extra info
for the value, e.g.:
sercmd> mi pwd
200 OK
+ WD:: /home/andrei/sr.git
The same info will appear in xmlrpc and I assume that
this is not what
is expected (it should be only "/home/andrei/sr.git", at least that's
the output of core.pwd).
Another possible problem is the ARRAY type for xmlrpc (the xmlrpc
specifications doesn't support multiple return values in the same reply,
but it does support returning an array). So far in ser an rpc function
returning an array must be marked explicitly (the RET_ARRAY flag).
That would be a problem for mi commands that return multiple values
(either the mi_rpc modules should know them somehow and add the RET_ARRAY
flag automatically for them, or we should change the xmlrpc value to
automatically detect if an array is needed). Note that this problem
appears only for the xmlrpc transport, for the binrpc/ctl transport it
doesn't matter since it supports multiple values in replies.
What we would need are some example mi_xmlrpc replies from kamailio and the
same replies from sr xmlrpc via mi_rpc.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com/