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 <o...@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 > <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 > > > > > > -- > 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