<div dir="ltr"><div>The one thing we find annoying about deprecating this is that it's not a drop in replacement for the current xmlrpc implementation. We have a lot of system level monitoring an alerting (things like fraud checking, rate limiting, reporting to external systems) that rely upon accessing fifo via xmlrpc, and the format for the content responses returned by the new mi_xmlrpc_ng module is not the same as the old module (I don't remember the details off the top of my head, but basically it was a difference being double colon delimited and something else).</div>
<div> </div><div>It would really be beneficial if there was a way to control or configure the format of the xml response to line up the same as the old formatting, so that we could use it as a drop in replacement and not have to go rewrite a hundred different alerts/scripts that rely upon mi_xmlrpc's current format.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
I would appreciate your input/opinions in the matter of deprecating the mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.<br>
<br>
Both modules offer the same functionality : XMLRPC backend for the Management Interface (see <a href="http://ww.opensips.org/Documentation/Interface-MI-1-10" target="_blank">ww.opensips.org/Documentation/<u></u>Interface-MI-1-10</a>).<br>
<br>
The old mi_xmlrpc module use the libxmlrpc-c3 external library for the HTTP server and XMLRPC engine. This library was a source of problems along the years because of the difficulty in using it (threads versus processes support) -> the user experience was horrible in trying to have this library properly working on various OS distros.<br>
<br>
The new mi_xmlrpc_ng module uses the httpd support from OpenSIPS and the generic libxml library - this is a safer and more robust approach ; users will find really easy to deploy these modules, to configure them (not to mention flexibility when comes to setting, restricting access, etc).<br>
<br>
So, I would suggest to terminate the mi_xmlrpc module and officially have the mi_xmlrpc_ng module for the XMLRPC backend.<br>
<br>
Comments, opinions are, as always, more than welcome.<br>
<br>
References :<br>
- mi_xmlrpc module - <a href="http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html" target="_blank">http://www.opensips.org/html/<u></u>docs/modules/1.10.x/mi_xmlrpc.<u></u>html</a><br>
- mi_xmlrpc_ng module - <a href="http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html" target="_blank">http://www.opensips.org/html/<u></u>docs/modules/1.10.x/mi_xmlrpc_<u></u>ng.html</a><br>
<br>
Regards,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Bogdan-Andrei Iancu<br>
OpenSIPS Founder and Developer<br>
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.<u></u>com</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-<u></u>bin/mailman/listinfo/users</a><br>
</font></span></blockquote></div><br></div>