Hello all,
Bringing some light here : none of the xmlrpc implementations offer a
structured reply
From the "deprecation" point of view, we need to be sure:
1) the new mi_xmlrpc-ng module is a perfect substitute to the old one
(providing the same unstructured reply)
2) the new mi_xmlrpc-ng module can also provide a structured reply -
this definitely is something good for the future
3) OpenSIPS CP must be migrated (there are some things that need to be
changed) to be compatible with both modules.
Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working
to achieve the 3 goals above (many thanks to both of them).
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.
Many thanks,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 19.03.2014 21:55, Brett Nemeroff wrote:
JSON+http sounds fantastic. It's like.. Starting to sound a like a
RESTful server.
I'm pretty sure others will jump on this. I know I would.
-Brett
On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas <o...@voipembedded.com
<mailto:o...@voipembedded.com>> wrote:
The new module is built on top of the httpd module which has a
parameter to define the size of the buffer. If you need large
replies, then you need to adjust the buffer size accordingly.
http://www.opensips.org/html/docs/modules/devel/httpd
That buffer is used by all modules that are sitting on top of the
httpd module, and there's one single process dedicated to all http
requests (no interference with SIP workers).
Regards,
Ovidiu Sas
On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff
<br...@nemeroff.com <mailto:br...@nemeroff.com>> wrote:
> 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.
>
> 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.
>
> 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.
>
> -Brett
>
>
>
> On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev
<goup2...@gmail.com <mailto:goup2...@gmail.com>>
> wrote:
>>
>> 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!
>>
>>
>> 2014-03-19 21:07 GMT+02:00 Brett Nemeroff <br...@nemeroff.com
<mailto:br...@nemeroff.com>>:
>>
>>> 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
<o...@voipembedded.com <mailto:o...@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
<br...@nemeroff.com <mailto:br...@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
>>>> > <bog...@opensips.org <mailto:bog...@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:
>>>> >>
>>>> >> Will this affect OpenSIPS-CP?
>>>> >>
>>>> >> Regards,
>>>> >> Ali Pey
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh <kne...@yahoo.com
<mailto:kne...@yahoo.com>> wrote:
>>>> >>>
>>>> >>> I'm all for the deprecation as long as the documentation
on the
>>>> >>> mi_xmlrpc_ng module is updated to a usable level. I find
myself
>>>> >>> referencing
>>>> >>> the documentation for xmlrpc and hoping that it holds
true for
>>>> >>> xmlrpc_ng.
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Users mailing list
>>>> >>> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Users mailing list
>>>> >> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Users mailing list
>>>> >> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Users mailing list
>>>> > Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> VoIP Embedded, Inc.
>>>> http://www.voipembedded.com
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org <mailto:Users@lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
