<div dir="ltr">I think there are some other issues with the size of the return data. I know for one that the mi_udp method has a buffer size limit. If you hit this limit I think it very quietly truncates the data. I can't 100% verify that since it's been a long time since I've used it.<div>
<br></div><div>I believe you can paginate the data, but the problem is that you can't guarantee consistent results paginating data when the data is changing constantly. I'm not really sure on the background how this is handled; maybe a locked list or something.. but not sure if it'd affect performance at high velocity. Seems like something. somewhere would be affected.. either performance or accuracy. </div>
<div><br></div><div>My point being, care needs to be taken that the method can produce consistent results; even for large datasets. If data is going to be truncated or we run out of SHM, there needs to not only be an error log, but I think the out put needs to say something as well. </div>
<div><br></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:37 PM, Dragomir Haralambiev <span dir="ltr"><<a href="mailto:goup2010@gmail.com" target="_blank">goup2010@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I totally share Brett's feelings! For me dlg_list_ctx over the new module causes lots of headaches when dialogs go over 100 or so. Structured output would resolve such problems. I am totally in for structured SJON format too!<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-19 21:07 GMT+02:00 Brett Nemeroff <span dir="ltr"><<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>></span>:<div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr">I think the only reason for that is backwards compatibility with stuff written for the other mi interfaces.<div><br></div><div><br></div><div>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. </div>
<div><br></div><div>For little things like "dr_reload" I don't really care.</div><div><br></div><div>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? </div>
<div><br></div><div>I personally would love to see it structured in JSON format. :) </div><span><font color="#888888"><div><br></div><div>-Brett</div><div><br></div></font></span></div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 2:05 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:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">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 it.<br>
<br>
Regards,<br>
Ovidiu Sas<br>
<div><div><br>
<br>
On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff <<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>> wrote:<br>
> I'd like to see the new module to be a drop in replacement for the old 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 <<a href="mailto:bogdan@opensips.org" target="_blank">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" target="_blank">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 referencing<br>
>>> the documentation for xmlrpc and hoping that it holds true for xmlrpc_ng.<br>
>>><br>
>>> _______________________________________________<br>
>>> Users mailing list<br>
>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div><div>--<br>
VoIP Embedded, Inc.<br>
<a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
<br>
</div><div><div>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">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>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">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></blockquote></div></div></div><br></div></div>
<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></blockquote></div><br></div>