[OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Oct 7 15:14:11 CEST 2014
Ovidiu, we are still somewhere in the middle of a release cycle, so
enough time to eventually fix potential problems. I agree with you, we
need to take the step and face the outcome.
We need to prepare a directly on the repo, like "modules_old" where to
move the obsolete modules.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.10.2014 15:43, Ovidiu Sas wrote:
>
> There was a lot of work done right before releasing 1.11 to fix the
> compatibility issue. I didn't heard back anything, so I assume that
> it's fixed.
>
> Anyway, if there's no push for it, the transition will never happen :)
>
> -ovidiu
>
> On Oct 7, 2014 5:24 AM, "Bogdan-Andrei Iancu" <bogdan at opensips.org
> <mailto:bogdan at opensips.org>> wrote:
>
> Hi Ovidiu,
>
> We need to check once again if the mi_xmlrpc_ng can do a perfect
> replace for mi_xmlrpc - then we can obsolete in a blink of an eye.
>
> Are you aware of any pending issues in terms of backward
> compatibility ?
>
> PS: 1.12 is replaced by 2.1.0 - this is the version on trunk.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 25.09.2014 21 <tel:25.09.2014%2021>:39, Ovidiu Sas 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
>
>
>
>
>
> _______________________________________________
> 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/96fd9170/attachment-0001.htm>
More information about the Users
mailing list