<div dir="ltr">On Wed, Oct 23, 2013 at 10:37 AM, Paul Albrecht <span dir="ltr"><<a href="mailto:palbrecht@glccom.com" target="_blank">palbrecht@glccom.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Let's say, for example, I want to write my own application for conferencing. Today I can write a module to do that because asterisk provides interfaces to register a dial plan application, extend asterisk commands, and emit new events. With my new dial plan application which supports conferencing actions/events I can control callers with a script written in my favorite programming language which receives events, like dtmf, from my application, taking appropriate actions to run my conferences.</div>
</blockquote><div><br></div><div>Sure, anything is possible -- it's just code.  But writing a new conferencing application in C code is much harder (and fraught with danger with regards to memory management, locking, embedding another scripting language) than writing such an application using ARI.  In short, ARI exposes some of the basic building blocks (answering calls/playing sounds/recording audio/dealing with channel bridges/playing indications), and leaves you to build the logic around those blocks in an external language of your choice.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Given all this I don't see how you can possibly maintain ARI/Stasis is *NOT* reinventing the AMI wheel. In fact, seems like it's a step backwards because it wasn't designed for third party developers.</div>
</div></div></blockquote><div><br></div><div>Sure, there's going to be some overlap between what you can do with ARI and what you can do with AMI.  Take, for example, getting information about a particular channel in use.  In AMI, you'd issue the "Status" command.  In ARI, you'd call the /ari/channels/{ChannelId} resource.  It's obvious that when you're dealing with basic channel operations, there is going to be some duplication of effort.  The point that you don't seem to be getting is that ARI is mostly about an external application controlling the logic of a call *on a (mostly) channel-oriented basis*.  AMI, on the other hand, is mostly about an external application controlling an Asterisk system *on a (mostly) non-channel-oriented basis*.   As I attempted to explain earlier, the vision of ARI is to have it be much more of a replacement for Async AGI and ExternalIVR than it is for it to be an AMI replacement.<br>
<br></div><div>I don't know how you can say it wasn't designed for third-party developers -- that's *exactly* who it was designed for.  If you had the choice of writing a new conferencing app (to use your example) or queueing app or voicemail app, would you really prefer to write it in C?  I know I wouldn't.  I'd prefer to write it in Python or NodeJS or, heaven forbid, Perl.  One of the prominent reasons for building ARI was to help get Asterisk out of the business of having one canonical way of handing voicemail, for example, and instead allow integrators and end users to script the logic to fit their needs, in something easier than C code.  Modern developers are obviously more likely to get involved in writing their own logic if they can do it using something like REST and websockets.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Seems like ARI/stasis is a solution to a non-problem architected by people who don't understand how asterisk works or how asterisk is used by third party developers.</div>
</div></div></blockquote><div><br></div><div>That's a pretty bold statement, and one which probably doesn't even justify a response, but I'll respond anyway.  If you had actually looked to see who has done the development work on ARI, and who has helped to make it better, you'd hopefully realize that they *do* know how Asterisk works, as they're some of the principle developers of Asteris, and they *do* know how Asterisk is used by third-party developers.  Just because you haven't caught the vision of ARI doesn't mean it's not a useful tool for those of us who choose to use it, and it certainly doesn't justify attacking the people who wrote ARI.<br>
<br>--<br></div><div>Jared Smith<br></div></div></div></div>