<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">
On 10/28/2014 06:03 PM, Ben Langfeld wrote:<br class="">
</div>
<blockquote cite="mid:CAAyX+KGSxxOvQ7fkjybNwFwgrKtz8pBwCP7nP_U3nzBpfP8JMQ@mail.gmail.com" type="cite" class="">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On 28 October 2014 19:47, Derek
Andrew <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:Derek.Andrew@usask.ca" target="_blank" class="">Derek.Andrew@usask.ca</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote">
<div dir="ltr" class="">
<div class="gmail_extra">What is the alternative to the
dial plan? Is everyone talking about getting rid of
the statements like:<br class="">
exten => s,1,<br class="">
</div>
<div class="gmail_extra"><br class="">
</div>
<div class="gmail_extra">what is the alternative? <br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
Remote applications based on APIs like ARI. This is the
start of the discussion, and please remember that nothing
has been decided or even presented as a robust plan yet.
This is brain-storming.</div>
<div class=""><br class="">
</div>
<div class="">Additionally, note that the original proposal was to
deprecate AMI/AGI in favour of ARI once it is feature
complete with those protocols; an entirely lesser change
than the removal of the dialplan in its entirety.</div>
<div class=""> </div>
</div></div></div></blockquote></div></div></blockquote></div><br class=""><div class="">Since this thread has my name on it, I guess it’s past time that I explain my motivation for making the suggestion, and try to restore some of the context that was present in the discussion at AstriDevCon.</div><div class=""><br class=""></div><div class="">Before I jump into the details of my proposal, I’d like to clarify terms:</div><div class=""><br class=""></div><div class="">* Deprecating something means that the project decides to no longer recommend its use. It does NOT mean immediate removal. As others on the list have pointed out, Asterisk 13 is out and will be supported for 5 years. Anything that is *deprecated* in Asterisk 14 or even 15 is likely to still be *supported*, just *not recommended*. That means that anything we decide to deprecate today is likely to be available for at least 7 years (2 years to next LTS release + 5 years of support). Given the excellent history of the Asterisk project at being backward compatible, it may even be longer than that. I’d say exactly how long depends on the community and the interest in maintaining it.</div><div class=""><br class=""></div><div class="">* Removing something means it is gone from Asterisk. I made no proposals to remove anything, only to deprecate.</div><div class=""><br class=""></div><div class="">Deprecating things is an important function of software projects. It allows us to gradually cut ties on old functionality that has been superseded and to focus development efforts and available resources on the replacement features. Deprecating gives the community a chance to communicate that at some point in the future, a feature will stop working. Until that time, when the deprecation graduates to removal, the feature is still supported. If we never deprecated anything, the project would eventually grind to a halt because we would spend all our time making sure that each new feature was compatible all the way back to Asterisk 1.0. Clearly there’s a middle ground. I’d like to consider deprecating features that can have viable replacements so we can appropriately focus our limited community resources.</div><div class=""><br class=""></div><div class="">Now, on to what I originally proposed.</div><div class=""><br class=""></div><div class="">I don’t *think* anyone actually recommended deprecating extensions.conf. There was a suggestion (by Leif I think, and in any event, I agree with it) that it might be nice to have the ability to control calls in Asterisk that never touch the extensions.conf. Control would come via ARI from external applications. Not having to configure the dialplan basically saves a step and makes it ever so slightly easier for application developers who don’t care about extensions.conf. From my perspective, and that of many Adhearsion applications, our extensions.conf is essentially empty except for the line that routes the call to AGI.</div><div class=""><br class=""></div><div class="">For anyone who doesn’t want to use ARI, extensions.conf would continue to be available. I also agree with other posters to this thread who argue that not everything needs to be handled by an external application. For those cases, extensions.conf is sufficient.</div><div class=""><br class=""></div><div class="">I am not in favor of deprecating or removing extensions.conf at this time.</div><div class=""><br class=""></div><div class="">However, I most certainly did propose to deprecate AMI and AGI. As protocols they have several significant drawbacks:</div><div class=""><br class=""></div><div class="">* AMI has historically had many problems with internal consistency. While that has improved dramatically, it’s still a difficult protocol to write generic parsers for due to the amount of state you have to track and the edge cases you have to consider.</div><div class="">* AGI’s has two fatal flaws: 1) it is blocking. Once you start a Dial or Playback, you can’t do anything else until it completes. 2) It depends on Dialplan applications - if there isn’t a dialplan application, you can’t do it.</div><div class="">* AGI additionally suffers from the fact that its ability to return information is severely limited. Each AGI command results in a single code (which isn’t consistently used to indicate error or success) and many of the actually useful pieces of information you want returned from AGI actually have to come in the form of channel variables. Channel variables aren’t technically part of AGI at all, but rather the responsibility of the dialplan application that created them. This makes documentation difficult.</div><div class="">* AGI (and dialplan) have hard-coded limits of 1024 bytes of input. This causes all kinds of breakage when you need to pass more data, such as a long text-to-speech string</div><div class="">* AMI and AGI were not invented with Unicode in mind. Internationalization is already important and will only become more so.</div><div class="">* AMI and AGI have some overlap (you start calls with AMI, but you control them with AGI; if you want to transfer a call you do that with AMI, not AGI) - but neither protocol is sufficient for call control alone. Thus Adhearsion chose to use AsyncAGI, which is really AGI over AMI, and not really async. We fake AGI into appearing asynchronous by using AMI Redirect to transfer a call back to ourselves. This breaks the AGI control and allows us to issue the next command. It works, but it has some serious drawbacks.</div><div class=""><br class=""></div><div class="">It is my opinion that while AGI and AMI are probably individually fixable, doing so would cause backward-incompatible changes. And even in that event, application developers would still have to contend with two interfaces to Asterisk, not one.</div><div class=""><br class=""></div><div class="">Enter ARI. ARI is obviously still very early, but shows great potential. Despite using a technology labeled as “web sockets”, this is really just to make it easier for web developers. Web sockets aren’t all that different from regular sockets, and you don’t require a web browser to make use of that interface. Many, many services on the internet communicate using “web services” with no browser in sight, simply because HTTP is a convenient transport. JSON as a serialization mechanism is far superior to the manual and inconsistent serialization that happens in AGI and AMI. JSON serialization also benefits from having deserializers readily available in any language.</div><div class=""><br class=""></div><div class="">ARI doesn’t yet do everything AMI or AGI do, but extending it to do so is a straightforward operation that should require only minimal changes to the ARI’s interfaces, mostly by adding new things. The semantics of HTTP are very well understood and well documented. As a protocol, that’s nice to have. ARI simply layers on top of that to provide the functionality we want.</div><div class=""><br class=""></div><div class="">My message isn’t about defending ARI though, it’s about the future of interfacing with Asterisk, and I think the consensus from AstriDevCon was that ARI is the future of interfacing with Asterisk.</div><div class=""><br class=""></div><div class="">If we are going to adopt ARI and make it do everything we need it to do, then EVENTUALLY, SOMEDAY, we won’t need AMI and AGI. My proposal was about that: focusing the development community’s efforts on a single interface and improving it to do all of the things we need it to do. Rather than continue to extend and enhance and develop two separate protocols that have known limitations and difficult backward-compatibility promises, I propose to focus our efforts on a single interface that we can carefully design and document. AMI and AGI will continue to exist for the foreseeable future to support all those application that are deployed to production today. But for developers who sit down today to write the next generation application, I propose that we, the Asterisk community, encourage them to use ARI for those applications, and to allow AMI/AGI to slowly slide into obscurity.</div><div class=""><br class=""></div><div class="">/BAK/</div><div class=""><br class=""></div><div class=""><span style="text-align: -webkit-auto; orphans: 2; widows: 2;" class="">-- </span></div><div class=""><div class=""><div style="orphans: 2; text-align: -webkit-auto; widows: 2; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; text-align: -webkit-auto; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; text-align: -webkit-auto; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Ben Klang</div><div class="">Principal/Technology Strategist, Mojo Lingo</div><div class=""><a href="mailto:bklang@mojolingo.com" class="">bklang@mojolingo.com</a></div><div class="">+1.404.475.4841</div><div class=""><br class=""></div><div class="">Mojo Lingo -- <i class="">Voice applications that work like magic</i></div><div class=""><a href="http://mojolingo.com/" class="">http://mojolingo.com</a></div></div><div class="">Twitter: @MojoLingo</div><div class=""><br class=""></div></div></span></div></span></div></span></div></span></div></div></div></body></html>