[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc

Tue Oct 7 11:24:17 CEST 2014

Hi Ovidiu,

We need to check once again if the mi_xmlrpc_ng can do a perfect replace 
for mi_xmlrpc - then we can obsolete in a blink of an eye.

Are you aware of any pending issues in terms of backward compatibility ?

PS: 1.12 is replaced by 2.1.0 - this is the version on trunk.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 25.09.2014 21:39, Ovidiu Sas wrote:
> Are we ready to deprecate the mi_xmlrpc module now (for 1.12)?
>
> -ovidiu
>
> On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org> wrote:
>> 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 <osas at 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 <brett at 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
>>>> <goup2010 at 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 <brett at 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 <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:
>>>>>>>>>
>>>>>>>>> Will this affect OpenSIPS-CP?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Ali Pey
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh <kneeoh at 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 at lists.opensips.org
>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users at lists.opensips.org
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users at lists.opensips.org
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>