[sr-dev] mi vs RPC

Andrei Pelinescu-Onciul andrei at iptel.org
Tue Jul 7 13:24:58 CEST 2009


On Jul 07, 2009 at 12:58, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> On 07/07/2009 12:40 AM, Andrei Pelinescu-Onciul wrote:
> >On Jul 06, 2009 at 23:42, Daniel-Constantin Mierla <miconda at gmail.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.
> >>    
> >
> >What are attributes used for? I don't see them mapping to anything in
> >terms of xmlrpc or standard rpc.
> >Is anybody using the attributes?
> >  
> 
> 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).

> 
> 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? Is it something used by seas?

> >  
> >>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.
BTW: is it ok with you if I add more functions to mi_rpc? 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).

> 
> 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. 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.).

> 
> 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



More information about the sr-dev mailing list