<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Hello all,<br>
<br>
Bringing some light here : none of the xmlrpc implementations
offer a structured reply<br>
<br>
From the "deprecation" point of view, we need to be sure:<br>
1) the new mi_xmlrpc-ng module is a perfect substitute to the
old one (providing the same unstructured reply)<br>
2) the new mi_xmlrpc-ng module can also provide a structured
reply - this definitely is something good for the future<br>
3) OpenSIPS CP must be migrated (there are some things that need
to be changed) to be compatible with both modules.<br>
<br>
Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily
working to achieve the 3 goals above (many thanks to both of
them).<br>
<br>
As noticed, the old mi_xmlrpc module was not deprecated in 1.11
- there are small but many things to be done to 100% ensure a
smooth transition. Still this is work on progress and it will be
done for next release.<br>
<br>
Many thanks,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
On 19.03.2014 21:55, Brett Nemeroff wrote:<br>
</div>
<blockquote
cite="mid:CAPwC5wzSsbiJmR+TgsMj0jQ-cK7jtUCxO_WO_MLg4gHevY+N5w@mail.gmail.com"
type="cite">
<div dir="ltr">JSON+http sounds fantastic. It's like.. Starting to
sound a like a RESTful server.
<div><br>
</div>
<div>I'm pretty sure others will jump on this. I know I would.</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:52 PM, Ovidiu
Sas <span dir="ltr"><<a moz-do-not-send="true"
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">The new
module is built on top of the httpd module which has a<br>
parameter to define the size of the buffer. If you need
large<br>
replies, then you need to adjust the buffer size
accordingly.<br>
<a moz-do-not-send="true"
href="http://www.opensips.org/html/docs/modules/devel/httpd"
target="_blank">http://www.opensips.org/html/docs/modules/devel/httpd</a><br>
<br>
That buffer is used by all modules that are sitting on top
of the<br>
httpd module, and there's one single process dedicated to
all http<br>
requests (no interference with SIP workers).<br>
<br>
Regards,<br>
Ovidiu Sas<br>
<div class="HOEnZb">
<div class="h5"><br>
On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff <<a
moz-do-not-send="true"
href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>>
wrote:<br>
> I think there are some other issues with the size
of the return data. I know<br>
> for one that the mi_udp method has a buffer size
limit. If you hit this<br>
> limit I think it very quietly truncates the data. I
can't 100% verify that<br>
> since it's been a long time since I've used it.<br>
><br>
> I believe you can paginate the data, but the
problem is that you can't<br>
> guarantee consistent results paginating data when
the data is changing<br>
> constantly. I'm not really sure on the background
how this is handled; maybe<br>
> a locked list or something.. but not sure if it'd
affect performance at high<br>
> velocity. Seems like something. somewhere would be
affected.. either<br>
> performance or accuracy.<br>
><br>
> My point being, care needs to be taken that the
method can produce<br>
> consistent results; even for large datasets. If
data is going to be<br>
> truncated or we run out of SHM, there needs to not
only be an error log, but<br>
> I think the out put needs to say something as well.<br>
><br>
> -Brett<br>
><br>
><br>
><br>
> On Wed, Mar 19, 2014 at 2:37 PM, Dragomir
Haralambiev <<a moz-do-not-send="true"
href="mailto:goup2010@gmail.com">goup2010@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I totally share Brett's feelings! For me
dlg_list_ctx over the new module<br>
>> causes lots of headaches when dialogs go over
100 or so. Structured output<br>
>> would resolve such problems. I am totally in
for structured SJON format too!<br>
>><br>
>><br>
>> 2014-03-19 21:07 GMT+02:00 Brett Nemeroff <<a
moz-do-not-send="true"
href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>>:<br>
>><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<br>
>>> dlg_list_ctx.. Parsing it is kind of
ridiculous... Anyone else share this<br>
>>> 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 moz-do-not-send="true"
href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>><br>
>>> 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 moz-do-not-send="true"
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<br>
>>>> > 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<br>
>>>> > 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>>> >>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>>> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>>> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>>> > <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> Users mailing list<br>
>>>> <a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>