On Mon, Jun 16, 2014 at 9:28 AM, Damir Kalashnikov <kalashnikovdamir@xxxxxxxxx> wrote:
Does this mean that ARI will never jump to 2.0.0? No - but it is something that we would debate aggressively on this mailing list before doing, and we would explore all possible options before making such a decision.Matthew,I was not explicit - I meant scaling UP on a single machine. I plan to have a cluster installation in future but for first version it will be a single machine installation. We will be able to get a beefy machine in terms of specs, but nothing extraordinary (up to 8 core Intel CPU and up to 32GB of RAM).We do not plan do a lot of I/O or CPU intensive things, 90% of time connecting and routing incoming calls, collecting call statistics. 10% playing saved audio and voicemail.My main performance related concern was, if asterisk can support having 200 simultaneous channels sitting in stasis application/s, and 90% of those channels are in a state when they are connected to one another or to external line (i.e. no CPU or I/O intensive work is being done). From what I understood, it does not look like a problem.Regarding stability of ARI. Are currently exposed ARI APIs stable enough to the point that I can rely on them in production (at least to the extent that I could rely on Asterist 11 version of FastAGI) ?
ARI uses semantic versioning [1]. The current version is 1.3.0 - which means no backwards incompatible changes have been introduced. All additions have been backwards compatible changes or bug fixes.
I wouldn't expect that we would do this in a release branch either, unless we had no other option.
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
