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 <[email protected]> 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 <[email protected]> > 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 < > [email protected]> > > 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 <[email protected]>: > >> > >>> 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 <[email protected]> > >>> 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 <[email protected]> > >>>> 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 > >>>> > <[email protected]> > >>>> > 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 <[email protected]> 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 > >>>> >>> [email protected] > >>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Users mailing list > >>>> >> [email protected] > >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> >> > >>>> >> > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Users mailing list > >>>> >> [email protected] > >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> >> > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Users mailing list > >>>> > [email protected] > >>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> VoIP Embedded, Inc. > >>>> http://www.voipembedded.com > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> [email protected] > >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> [email protected] > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> [email protected] > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
