[RFC] Deprecating mi_xmlrpc

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] Deprecating mi_xmlrpc

Bogdan-Andrei Iancu-2
Hello all,

I would appreciate your input/opinions in the matter of deprecating the
mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.

Both modules offer the same functionality : XMLRPC backend for the
Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).

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.

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).

So, I would suggest to terminate the mi_xmlrpc module and officially
have the mi_xmlrpc_ng module for the XMLRPC backend.

Comments, opinions are, as always, more than welcome.

References :
     - mi_xmlrpc module -
http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
     - mi_xmlrpc_ng module -
http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html

Regards,

--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

fabio4prez
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).
 
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.


On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hello all,

I would appreciate your input/opinions in the matter of deprecating the mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.

Both modules offer the same functionality : XMLRPC backend for the Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).

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.

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).

So, I would suggest to terminate the mi_xmlrpc module and officially have the mi_xmlrpc_ng module for the XMLRPC backend.

Comments, opinions are, as always, more than welcome.

References :
    - mi_xmlrpc module - http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
    - mi_xmlrpc_ng module - http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html

Regards,

--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
Please open a bug report with all the details.
We will take a look at it and see what can be done before the release.

Regards,
Ovidiu Sas

On Tue, Mar 11, 2014 at 9:48 PM, Bobby Smith <[hidden email]> wrote:

> 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).
>
> 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.
>
>
> On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <[hidden email]>
> wrote:
>>
>> Hello all,
>>
>> I would appreciate your input/opinions in the matter of deprecating the
>> mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.
>>
>> Both modules offer the same functionality : XMLRPC backend for the
>> Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).
>>
>> 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.
>>
>> 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).
>>
>> So, I would suggest to terminate the mi_xmlrpc module and officially have
>> the mi_xmlrpc_ng module for the XMLRPC backend.
>>
>> Comments, opinions are, as always, more than welcome.
>>
>> References :
>>     - mi_xmlrpc module -
>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
>>     - mi_xmlrpc_ng module -
>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html
>>
>> Regards,
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Bogdan-Andrei Iancu-2
Hi,

What Bobby state is really true - already had some chat with Ovidiu in
evaluating the differences (on the reply format) and the effort to align
the new xmlrpc-ng module with the old one.

If this will be doable by tomorrow, we will drop mi_xmlrpc module in
1.11. If not, it will be kept for one more release.

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 14.03.2014 03:07, Ovidiu Sas wrote:

> Please open a bug report with all the details.
> We will take a look at it and see what can be done before the release.
>
> Regards,
> Ovidiu Sas
>
> On Tue, Mar 11, 2014 at 9:48 PM, Bobby Smith <[hidden email]> wrote:
>> 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).
>>
>> 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.
>>
>>
>> On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <[hidden email]>
>> wrote:
>>> Hello all,
>>>
>>> I would appreciate your input/opinions in the matter of deprecating the
>>> mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.
>>>
>>> Both modules offer the same functionality : XMLRPC backend for the
>>> Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> So, I would suggest to terminate the mi_xmlrpc module and officially have
>>> the mi_xmlrpc_ng module for the XMLRPC backend.
>>>
>>> Comments, opinions are, as always, more than welcome.
>>>
>>> References :
>>>      - mi_xmlrpc module -
>>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
>>>      - mi_xmlrpc_ng module -
>>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html
>>>
>>> Regards,
>>>
>>> --
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Dragomir Haralambiev
Hello,

The new mi_xmlrpc_ng module have one big probelm - not support integer value.

To send digit value OpenSips want to use srting.

Example:
When try to change debug level I must ot send "debug 1".

workable XML this is :
   <methodCall>
    <methodName>debug</methodName>
    <params>
   <param>
         <value> <string>1</string> </value></param>
    </params>
    </methodCall>

The right way is:
   <methodCall>
    <methodName>debug</methodName>
    <params>
   <param>
         <value> <integer>1</integer> </value></param>
    </params>
    </methodCall>

Best regards,
PlayMen


2014-03-19 11:13 GMT+02:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi,

What Bobby state is really true - already had some chat with Ovidiu in evaluating the differences (on the reply format) and the effort to align the new xmlrpc-ng module with the old one.

If this will be doable by tomorrow, we will drop mi_xmlrpc module in 1.11. If not, it will be kept for one more release.

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 14.03.2014 03:07, Ovidiu Sas wrote:
Please open a bug report with all the details.
We will take a look at it and see what can be done before the release.

Regards,
Ovidiu Sas

On Tue, Mar 11, 2014 at 9:48 PM, Bobby Smith <[hidden email]> wrote:
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).

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.


On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <[hidden email]>
wrote:
Hello all,

I would appreciate your input/opinions in the matter of deprecating the
mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.

Both modules offer the same functionality : XMLRPC backend for the
Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).

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.

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).

So, I would suggest to terminate the mi_xmlrpc module and officially have
the mi_xmlrpc_ng module for the XMLRPC backend.

Comments, opinions are, as always, more than welcome.

References :
     - mi_xmlrpc module -
http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
     - mi_xmlrpc_ng module -
http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html

Regards,

--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users





_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Kneeoh
In reply to this post by Bogdan-Andrei Iancu-2
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ali Pey
Will this affect OpenSIPS-CP?

Regards,
Ali Pey



On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Bogdan-Andrei Iancu-2
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 <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by fabio4prez
Please pull from git, give it a try and let us know if everything is
working as expected with your old scripts.

Regards,
Ovidiu Sas

On Tue, Mar 11, 2014 at 9:48 PM, Bobby Smith <[hidden email]> wrote:

> 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).
>
> 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.
>
>
> On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu <[hidden email]>
> wrote:
>>
>> Hello all,
>>
>> I would appreciate your input/opinions in the matter of deprecating the
>> mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.
>>
>> Both modules offer the same functionality : XMLRPC backend for the
>> Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10).
>>
>> 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.
>>
>> 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).
>>
>> So, I would suggest to terminate the mi_xmlrpc module and officially have
>> the mi_xmlrpc_ng module for the XMLRPC backend.
>>
>> Comments, opinions are, as always, more than welcome.
>>
>> References :
>>     - mi_xmlrpc module -
>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
>>     - mi_xmlrpc_ng module -
>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html
>>
>> Regards,
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Kneeoh
Please let us know what's missing from the mi_xmlrpc_ng doc and it is
present in mi_xmlrpc doc.

Regards,
Ovidiu Sas

On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh <[hidden email]> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Dragomir Haralambiev
Hello Dragomir,

As I pointed to you in a previous e-mail, the "integer" is not really
supported by opensips.
Even if you send a value as integer, it will still be treated as
string and each module will decide if a conversion is required.
All you need to do is adjust your script to send out string for all
param values.
It might be as simple as quoting the variable in your script.

Regards,
Ovidiu Sas

On Wed, Mar 19, 2014 at 7:53 AM, Dragomir Haralambiev
<[hidden email]> wrote:

> Hello,
>
> The new mi_xmlrpc_ng module have one big probelm - not support integer
> value.
>
> To send digit value OpenSips want to use srting.
>
> Example:
> When try to change debug level I must ot send "debug 1".
>
> workable XML this is :
>    <methodCall>
>     <methodName>debug</methodName>
>     <params>
>    <param>
>          <value> <string>1</string> </value></param>
>     </params>
>     </methodCall>
>
> The right way is:
>    <methodCall>
>     <methodName>debug</methodName>
>     <params>
>    <param>
>          <value> <integer>1</integer> </value></param>
>     </params>
>     </methodCall>
>
> Best regards,
> PlayMen
>
>
> 2014-03-19 11:13 GMT+02:00 Bogdan-Andrei Iancu <[hidden email]>:
>
>> Hi,
>>
>> What Bobby state is really true - already had some chat with Ovidiu in
>> evaluating the differences (on the reply format) and the effort to align the
>> new xmlrpc-ng module with the old one.
>>
>> If this will be doable by tomorrow, we will drop mi_xmlrpc module in 1.11.
>> If not, it will be kept for one more release.
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 14.03.2014 03:07, Ovidiu Sas wrote:
>>>
>>> Please open a bug report with all the details.
>>> We will take a look at it and see what can be done before the release.
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Tue, Mar 11, 2014 at 9:48 PM, Bobby Smith <[hidden email]>
>>> wrote:
>>>>
>>>> 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).
>>>>
>>>> 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.
>>>>
>>>>
>>>> On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu
>>>> <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I would appreciate your input/opinions in the matter of deprecating the
>>>>> mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules.
>>>>>
>>>>> Both modules offer the same functionality : XMLRPC backend for the
>>>>> Management Interface (see
>>>>> ww.opensips.org/Documentation/Interface-MI-1-10).
>>>>>
>>>>> 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.
>>>>>
>>>>> 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).
>>>>>
>>>>> So, I would suggest to terminate the mi_xmlrpc module and officially
>>>>> have
>>>>> the mi_xmlrpc_ng module for the XMLRPC backend.
>>>>>
>>>>> Comments, opinions are, as always, more than welcome.
>>>>>
>>>>> References :
>>>>>      - mi_xmlrpc module -
>>>>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc.html
>>>>>      - mi_xmlrpc_ng module -
>>>>> http://www.opensips.org/html/docs/modules/1.10.x/mi_xmlrpc_ng.html
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Bogdan-Andrei Iancu
>>>>> OpenSIPS Founder and Developer
>>>>> http://www.opensips-solutions.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Brett Nemeroff
Based on your reply, my understanding is that you are not currently
using the structured format, but you would like to have it in the
future in JSON format.  Am I right?

-ovidiu

On Wed, Mar 19, 2014 at 3:07 PM, Brett Nemeroff <[hidden email]> wrote:

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



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Brett Nemeroff
I presently use either the raw fifo, the UDP fifo or the old XMLRPC method. They all return the same format which has double colon separated nodes. It's not easy to parse into an object by any language I know.

I've written parsers for it, but I don't like them. It seems like the structure isn't well suited for parsing. You ask me if I'm using the "structured" output. The only structured output I know of today is XML with the unstructured data in one element. Is there something else? 

I do prefer JSON. JSON parsers are a dime a dozen and easy to work with typically. There isn't a whole lot of bloat, like there is with XML (religious preference).. I'd like something like this:

[
    {
        "dlg_id": "1234:1234",
        "callid": "aaaabbbcccddd",
        "profile": {
            "foo": "bar",
            "bee": "baz"
        }
    },
    {
        "dlg_id": "9999:5432",
        "callid": "qqqwwwweeerrrr",
        "profile": {
            "foo": "bar",
            "bee": "baz"
        }
    }
]

That's my $0.02.. That being said, there's a very large embedded base expecting the old format as well, which I think needs to be continued to be supported until we can give adequate notice that it's being deprecated. 

Thanks!
-Brett



On Wed, Mar 19, 2014 at 2:13 PM, Ovidiu Sas <[hidden email]> wrote:
Based on your reply, my understanding is that you are not currently
using the structured format, but you would like to have it in the
future in JSON format.  Am I right?

-ovidiu

On Wed, Mar 19, 2014 at 3:07 PM, Brett Nemeroff <[hidden email]> wrote:
> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >>> [hidden email]
>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> [hidden email]
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> [hidden email]
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > [hidden email]
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Dragomir Haralambiev
In reply to this post by Brett Nemeroff
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Brett Nemeroff
So, you are using the raw format.
The mi_xmlrpc_ng module is using only the raw format.
The structured format in the old mi_xmlrpc module was not implemented
in the new module because it seems that it doesn't have enough
traction in the community (AFAIK).


As for returning JSON, that should be a feature request for a new
mi_json_http module :)
There's no point embedding JSON in xml.
And it seems that somebody already implemented it:

commit 02638044d434f5cf95aa8f8c69527115a702dccf
Author: Stephane Alnet <[hidden email]>
Date:   Fri Nov 1 01:18:58 2013 +0100

    Modified httpd to support `application/json` for our purposes.


Regards,
Ovidiu Sas


On Wed, Mar 19, 2014 at 3:27 PM, Brett Nemeroff <[hidden email]> wrote:

> I presently use either the raw fifo, the UDP fifo or the old XMLRPC method.
> They all return the same format which has double colon separated nodes. It's
> not easy to parse into an object by any language I know.
>
> I've written parsers for it, but I don't like them. It seems like the
> structure isn't well suited for parsing. You ask me if I'm using the
> "structured" output. The only structured output I know of today is XML with
> the unstructured data in one element. Is there something else?
>
> I do prefer JSON. JSON parsers are a dime a dozen and easy to work with
> typically. There isn't a whole lot of bloat, like there is with XML
> (religious preference).. I'd like something like this:
>
> [
>     {
>         "dlg_id": "1234:1234",
>         "callid": "aaaabbbcccddd",
>         "profile": {
>             "foo": "bar",
>             "bee": "baz"
>         }
>     },
>     {
>         "dlg_id": "9999:5432",
>         "callid": "qqqwwwweeerrrr",
>         "profile": {
>             "foo": "bar",
>             "bee": "baz"
>         }
>     }
> ]
>
> That's my $0.02.. That being said, there's a very large embedded base
> expecting the old format as well, which I think needs to be continued to be
> supported until we can give adequate notice that it's being deprecated.
>
> Thanks!
> -Brett
>
>
>
> On Wed, Mar 19, 2014 at 2:13 PM, Ovidiu Sas <[hidden email]> wrote:
>>
>> Based on your reply, my understanding is that you are not currently
>> using the structured format, but you would like to have it in the
>> future in JSON format.  Am I right?
>>
>> -ovidiu
>>
>> On Wed, Mar 19, 2014 at 3:07 PM, Brett Nemeroff <[hidden email]>
>> wrote:
>> > 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 <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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:

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecating mi_xmlrpc

Ovidiu Sas
In reply to this post by Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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
>>>> > <[hidden email]>
>>>> > 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 <[hidden email]> 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
>>>> >>> [hidden email]
>>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Users mailing list
>>>> >> [hidden email]
>>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Users mailing list
>>>> >> [hidden email]
>>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Users mailing list
>>>> > [hidden email]
>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> VoIP Embedded, Inc.
>>>> http://www.voipembedded.com
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
12