<div dir="ltr">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.<div>
<br></div><div>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? </div>
<div><br></div><div>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:</div>
<div><br></div><div><div>[</div><div> {</div><div> "dlg_id": "1234:1234",</div><div> "callid": "aaaabbbcccddd",</div><div> "profile": {</div><div>
"foo": "bar",</div>
<div> "bee": "baz"</div><div> }</div><div> },</div><div> {</div><div> "dlg_id": "9999:5432",</div><div> "callid": "qqqwwwweeerrrr",</div>
<div> "profile": {</div><div> "foo": "bar",</div><div> "bee": "baz"</div><div> }</div><div> }</div><div>]</div></div><div><br></div>
<div>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. </div>
<div><br></div><div>Thanks!</div><div>-Brett</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 2:13 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Based on your reply, my understanding is that you are not currently<br>
using the structured format, but you would like to have it in the<br>
future in JSON format. Am I right?<br>
<span class="HOEnZb"><font color="#888888"><br>
-ovidiu<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 19, 2014 at 3:07 PM, Brett Nemeroff <<a href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>> wrote:<br>
> I think the only reason for that is backwards compatibility with stuff<br>
> written for the other mi interfaces.<br>
><br>
><br>
> Honestly, my parsers for the MI output are ridiculous. It's really<br>
> complicated and prone to failure. I'd like to know if others share my<br>
> feeling here.<br>
><br>
> For little things like "dr_reload" I don't really care.<br>
><br>
> But for MI calls that return large amounts of user data, like dlg_list_ctx..<br>
> Parsing it is kind of ridiculous... Anyone else share this feeling?<br>
><br>
> I personally would love to see it structured in JSON format. :)<br>
><br>
> -Brett<br>
><br>
><br>
><br>
> On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>> wrote:<br>
>><br>
>> Hello Brett,<br>
>><br>
>> It is true that the structured output mode was not implemented in the<br>
>> new module.<br>
>> It seems that having the output in one big chunk is the preferred<br>
>> method in the community.<br>
>><br>
>> If there is a real demand for structured output, we can take a look into<br>
>> it.<br>
>><br>
>> Regards,<br>
>> Ovidiu Sas<br>
>><br>
>><br>
>> On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff <<a href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>><br>
>> wrote:<br>
>> > I'd like to see the new module to be a drop in replacement for the old<br>
>> > one..<br>
>> ><br>
>> > That being said...<br>
>> ><br>
>> > I was pretty surprised when I started down the path of the XMLRPC module<br>
>> > that the reply isn't structured. It was just one big object.<br>
>> ><br>
>> > I'd like a selectable option on the module so that it either operates:<br>
>> > 1. Legacy (one big output chunk)<br>
>> > 2. Structured, parable for each output node.<br>
>> ><br>
>> > Really if we are talking "deprecating" we need to support the old method<br>
>> > primarily or there will be a lot of broken code out there.<br>
>> ><br>
>> > -Brett<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, Mar 19, 2014 at 12:15 PM, Bogdan-Andrei Iancu<br>
>> > <<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>><br>
>> > wrote:<br>
>> >><br>
>> >> The whole idea is not to :)<br>
>> >><br>
>> >> But more tests need to be done.<br>
>> >><br>
>> >> Regards,<br>
>> >><br>
>> >> Bogdan-Andrei Iancu<br>
>> >> OpenSIPS Founder and Developer<br>
>> >> <a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a><br>
>> >><br>
>> >> On 19.03.2014 17:39, Ali Pey wrote:<br>
>> >><br>
>> >> Will this affect OpenSIPS-CP?<br>
>> >><br>
>> >> Regards,<br>
>> >> Ali Pey<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh <<a href="mailto:kneeoh@yahoo.com">kneeoh@yahoo.com</a>> wrote:<br>
>> >>><br>
>> >>> I'm all for the deprecation as long as the documentation on the<br>
>> >>> mi_xmlrpc_ng module is updated to a usable level. I find myself<br>
>> >>> referencing<br>
>> >>> the documentation for xmlrpc and hoping that it holds true for<br>
>> >>> xmlrpc_ng.<br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> Users mailing list<br>
>> >>> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> >>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Users mailing list<br>
>> >> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> >> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Users mailing list<br>
>> >> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> >> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Users mailing list<br>
>> > <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> > <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> VoIP Embedded, Inc.<br>
>> <a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
<br>
<br>
<br>
--<br>
VoIP Embedded, Inc.<br>
<a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>