The trunk (development code) was switched from 1.12.x to 2.1.x and you
can get the URL from http://www.opensips.org/Downloads/Downloads#toc4.
The trunk version is not for production. See the available versions here:
http://www.opensips.org/About/AvailableVersions
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 26.09.2014 16:48, Satish Patel wrote:
Where is the trunk git URL to download latest 1.12.x? does it ready
for production?
On Thu, Sep 25, 2014 at 2:39 PM, Ovidiu Sas <o...@voipembedded.com
<mailto:o...@voipembedded.com>> 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
>
--
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
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
