[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Oct 7 12:11:02 CEST 2014
The trunk (development code) was switched from 1.12.x to 2.1.x and you
can get the URL from http://www.opensips.org/Downloads/Downloads#toc4.
The trunk version is not for production. See the available versions here:
http://www.opensips.org/About/AvailableVersions
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 26.09.2014 16:48, Satish Patel wrote:
> Where is the trunk git URL to download latest 1.12.x? does it ready
> for production?
>
> On Thu, Sep 25, 2014 at 2:39 PM, Ovidiu Sas <osas at voipembedded.com
> <mailto:osas at voipembedded.com>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Users at lists.opensips.org>
> >> >>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> _______________________________________________
> >> >>>> >> Users mailing list
> >> >>>> >> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> _______________________________________________
> >> >>>> >> Users mailing list
> >> >>>> >> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>>> >>
> >> >>>> >
> >> >>>> >
> >> >>>> > _______________________________________________
> >> >>>> > Users mailing list
> >> >>>> > Users at lists.opensips.org <mailto: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 <mailto:Users at lists.opensips.org>
> >> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Users mailing list
> >> >>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Users mailing list
> >> >> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Users mailing list
> >> > Users at lists.opensips.org <mailto: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 <mailto:Users at lists.opensips.org>
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto: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 <mailto: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/c558f2fb/attachment-0001.htm>
More information about the Users
mailing list