[sr-dev] mi vs RPC

[Daniel-Constantin Mierla]

On 07/07/2009 01:24 PM, Andrei Pelinescu-Onciul wrote:
> [...]
>> there are some mi commands that set attributes in reply nodes, for 
>> example ul_dump -- I discovered while implementing the mi_rpc.
>>
>> As I am not a xmlrpc heavy user, I do not know if and how they map.
>>     
>
> They cannot map since xmlrpc has no support for attributes.
> I'm not sure what was the design goal of mi. If it was to enable full
> xmlrpc use it has failed (it uses xmlrpc in an extremely limited way and
> has some extra features that are not part of xmlrpc or any rpc I know).
>   

it started to map on xml-like format. Practically is a lightweight 
representation of a xml document.

>   
>> In mi, a node can have value and a set of attributes. Just for example 
>> (does not mean it is so right now in the code):
>>
>> <process pid="1234" childid="10">
>> UDP listener
>> </process>
>>     
>
> There are 2 ways of doing this using standard rpcs: either just list all
>  the values ( 1234,10,"udp listener" ....) and rely on having a fixed
>  number of records per process (that's what core.ps does), or use
> an array of structures, eg.:
> {
>  pid    = 1234
>  childid = 10
>  type = "UDP listener"
> }
>
> The advantage would be that this is a standard approach directly
> supported by xmlrpc (and other rpcs), so you don't need to deal with
> proprietary encodings (e.g. mi encoding over xmlrpc) and even the client
> code is much simpler.
>
>   
>>> What's that asynchronous command support? How can one use it using xmlrpc
>>> (AFAIK xmlrpc does not support async. mode)? Is anybody using it?
>>>  
>>>       
>> This is used by some tm commands, for example: t_uac -- request is sent 
>> in one process and reply could come back in another one. There are some 
>> structures cloned in shm, filled on callback.
>>     
>
> Does it mean that the xmlrpc reply is not sent immediately, but at a later
> point?
Yes, not sure for k xmlrpc since I haven't used it, but with 
fifo/udp/unixsock you can do it.

>  Is it something used by seas?
>   

No, seas has its own protocol to communicate with the sip proxy.

>>>> 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.
>>>>    
>>>>         
>>> We shouldn't remove anything now, but after the next release I don't see 
>>> any reason for keeping mi (other then maybe some legacy application that
>>> uses some obscure feature).
>>>  
>>>       
>> do you mean dropping MI the interface/library or the mi_xmlrpc? MI might 
>> take longer, but mi_xmlrpc can be done in the next release.
>>     
>
> I mean making mi obsolete for any new stuff. The existing mi functions
> should/can be replaced but that is not a priority.
>
> If people using mi_xmlrpc can tell us what they expect (some packet
> dump will be nice), we can modify mi_rpc to produce exactly the expected
> format and so we could make mi_xmlrpc obsolete immediately.
>   

ok making the module obsolete if we get same interfacing with mi_rpc, 
but let's keep it at least one release.

> BTW: is it ok with you if I add more functions to mi_rpc?

Feel free to add as much as you want and even change current reply 
format for mi command. It is formatted for printing to terminal, but not 
convenient for working directly with other applications. It is better to 
have another command for pretty formating.

>  I want to have
> a version more compatible with ser RPCs (no attributes, only the value).
> Unfortunately it will still be limited to string only and no structs
> (since mi doesn't support them, it would be very hard to automatically
> guess the best type).
>   

Actually you can have structs - nodes whose value are a list of nodes. 
If you look at the way is printed now, there is some indentation for 
these cases.


>> I agree rpc in ser is easier to handle from developer point of view, the 
>> concern I have in regard to xmlrpc(s) relates to the fact that is a 
>> limited implementation, for what ser needed. Seems to be more that what 
>> K needs in mi_xmlrpc, according to your review.
>>     
>
> Looking at the complex tree structures from mi, I thought mi_xmlrpc
> would do some very complex stuff. It turns out that is just a way of
> passing strings over xmlrpc (kind of the old fifo packed in xml, no
> xmlrpc feature is used).
>
>   
>> On the other hand, mi_xmlrpc uses a library from distro, which as aside 
>> being developed for this purpose and probably follows more the specs, 
>> proved to be buggy sometime.
>>     
>
> xmlrpc(s) uses also a library for doing the parsing.
parsing the xml content, via libxml2, but not a dedicated smlrpc 
library. Or I am missing something after a quick look and, iirc, it was 
mentioned in the docs somewhere.

>  The difference is,
> it does not use a separate library for HTTP, it just reuses ser SIP-TCP
> transport for HTTP (that's why you can call a sr route for each XMLRPC
> request and do extra stuff like authentication, certificate verification
> a.s.o.).
>   

This I see as a nice feature, since we can do IP auth and other checks 
that were not possible with k mi_xmlrpc library.

Cheers,
Daniel

>   
>> So, I have no personal preference, mi_xmlrpc can be migrated anytime to 
>> use the xmlrpc code from ser as long as it maintain the request/reply 
>> format that has it in k 1.5.x, for the sake of migration easiness.
>>
>>     
>
>
> Andrei
>   

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