[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc

Tue Oct 7 14:43:06 CEST 2014

There was a lot of work done right before releasing 1.11 to fix the
compatibility issue.  I didn't heard back anything, so I assume that it's
fixed.

Anyway, if there's no push for it, the transition will never happen :)

-ovidiu
On Oct 7, 2014 5:24 AM, "Bogdan-Andrei Iancu" <bogdan at opensips.org> wrote:

> 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
>>>
>>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20141007/81e7f91a/attachment-0001.htm>