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