[sr-dev] xmlrpc interfaces

[Daniel-Constantin Mierla]

On 07/06/2009 02:35 PM, Andrei Pelinescu-Onciul wrote:
> On Jul 04, 2009 at 12:14, Juha Heinanen <jh at tutpro.com> wrote:
>   
>> 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
>   

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
> 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com/