[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc

Ovidiu Sas osas at voipembedded.com
Wed Mar 19 20:48:23 CET 2014


So, you are using the raw format.
The mi_xmlrpc_ng module is using only the raw format.
The structured format in the old mi_xmlrpc module was not implemented
in the new module because it seems that it doesn't have enough
traction in the community (AFAIK).


As for returning JSON, that should be a feature request for a new
mi_json_http module :)
There's no point embedding JSON in xml.
And it seems that somebody already implemented it:

commit 02638044d434f5cf95aa8f8c69527115a702dccf
Author: Stephane Alnet <stephane at shimaore.net>
Date:   Fri Nov 1 01:18:58 2013 +0100

    Modified httpd to support `application/json` for our purposes.


Regards,
Ovidiu Sas


On Wed, Mar 19, 2014 at 3:27 PM, Brett Nemeroff <brett at nemeroff.com> wrote:
> I presently use either the raw fifo, the UDP fifo or the old XMLRPC method.
> They all return the same format which has double colon separated nodes. It's
> not easy to parse into an object by any language I know.
>
> I've written parsers for it, but I don't like them. It seems like the
> structure isn't well suited for parsing. You ask me if I'm using the
> "structured" output. The only structured output I know of today is XML with
> the unstructured data in one element. Is there something else?
>
> I do prefer JSON. JSON parsers are a dime a dozen and easy to work with
> typically. There isn't a whole lot of bloat, like there is with XML
> (religious preference).. I'd like something like this:
>
> [
>     {
>         "dlg_id": "1234:1234",
>         "callid": "aaaabbbcccddd",
>         "profile": {
>             "foo": "bar",
>             "bee": "baz"
>         }
>     },
>     {
>         "dlg_id": "9999:5432",
>         "callid": "qqqwwwweeerrrr",
>         "profile": {
>             "foo": "bar",
>             "bee": "baz"
>         }
>     }
> ]
>
> That's my $0.02.. That being said, there's a very large embedded base
> expecting the old format as well, which I think needs to be continued to be
> supported until we can give adequate notice that it's being deprecated.
>
> Thanks!
> -Brett
>
>
>
> On Wed, Mar 19, 2014 at 2:13 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>>
>> Based on your reply, my understanding is that you are not currently
>> using the structured format, but you would like to have it in the
>> future in JSON format.  Am I right?
>>
>> -ovidiu
>>
>> On Wed, Mar 19, 2014 at 3:07 PM, Brett Nemeroff <brett at nemeroff.com>
>> wrote:
>> > I think the only reason for that is backwards compatibility with stuff
>> > written for the other mi interfaces.
>> >
>> >
>> > Honestly, my parsers for the MI output are ridiculous. It's really
>> > complicated and prone to failure. I'd like to know if others share my
>> > feeling here.
>> >
>> > For little things like "dr_reload" I don't really care.
>> >
>> > But for MI calls that return large amounts of user data, like
>> > dlg_list_ctx..
>> > Parsing it is kind of ridiculous... Anyone else share this feeling?
>> >
>> > I personally would love to see it structured in JSON format. :)
>> >
>> > -Brett
>> >
>> >
>> >
>> > On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas <osas at voipembedded.com>
>> > wrote:
>> >>
>> >> Hello Brett,
>> >>
>> >> It is true that the structured output mode was not implemented in the
>> >> new module.
>> >> It seems that having the output in one big chunk is the preferred
>> >> method in the community.
>> >>
>> >> If there is a real demand for structured output, we can take a look
>> >> into
>> >> it.
>> >>
>> >> Regards,
>> >> Ovidiu Sas
>> >>
>> >>
>> >> On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff <brett at nemeroff.com>
>> >> wrote:
>> >> > I'd like to see the new module to be a drop in replacement for the
>> >> > old
>> >> > one..
>> >> >
>> >> > That being said...
>> >> >
>> >> > I was pretty surprised when I started down the path of the XMLRPC
>> >> > module
>> >> > that the reply isn't structured. It was just one big object.
>> >> >
>> >> > I'd like a selectable option on the module so that it either
>> >> > operates:
>> >> > 1. Legacy (one big output chunk)
>> >> > 2. Structured, parable for each output node.
>> >> >
>> >> > Really if we are talking "deprecating" we need to support the old
>> >> > method
>> >> > primarily or there will be a lot of broken code out there.
>> >> >
>> >> > -Brett
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Mar 19, 2014 at 12:15 PM, Bogdan-Andrei Iancu
>> >> > <bogdan at opensips.org>
>> >> > wrote:
>> >> >>
>> >> >> The whole idea is not to :)
>> >> >>
>> >> >> But more tests need to be done.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Bogdan-Andrei Iancu
>> >> >> OpenSIPS Founder and Developer
>> >> >> http://www.opensips-solutions.com
>> >> >>
>> >> >> On 19.03.2014 17:39, Ali Pey wrote:



More information about the Users mailing list