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" <bog...@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 >> <bog...@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 <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> >>>> 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> >>>>> 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>: >>>>>> >>>>>> 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> >>>>>>> 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 >>>>>>>> > >>>>>>>> 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> >>>>>>>>> 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> >>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> 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 >>>>>>>> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> 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 >>>> 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 >>> >>> >> >> > > _______________________________________________ > 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