7 Jul
2009
7 Jul
'09
7:24 a.m.
On Jul 07, 2009 at 12:58, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Does it mean that the xmlrpc reply is not sent immediately, but at a later
point? Is it something used by seas?
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).
On 07/07/2009 12:40 AM, Andrei Pelinescu-Onciul wrote:
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).
On Jul 06, 2009 at 23:42, Daniel-Constantin Mierla
<miconda(a)gmail.com>
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. 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?
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. 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).
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