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" <bog...@opensips.org
<mailto:bog...@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
<bog...@opensips.org <mailto:bog...@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
<o...@voipembedded.com <mailto:o...@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
<br...@nemeroff.com <mailto:br...@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
<goup2...@gmail.com <mailto:goup2...@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
<br...@nemeroff.com <mailto:br...@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 <o...@voipembedded.com
<mailto:o...@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 <br...@nemeroff.com
<mailto:br...@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
<bog...@opensips.org
<mailto:bog...@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 <kne...@yahoo.com
<mailto:kne...@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@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
