[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc

Wed Mar 19 20:55:25 CET 2014

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> 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>
> 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>
> > 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>:
> >>
> >>> 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>
> >>> 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>
> >>>> 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>
> >>>> > 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> 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
> >>>> >>> 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
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> Users mailing list
> >>>> >> 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
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> VoIP Embedded, Inc.
> >>>> http://www.voipembedded.com
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> 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
> >>>
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> 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
> >
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> 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/20140319/806070af/attachment-0001.htm>