> On 10/28/2014 06:03 PM, Ben Langfeld wrote: >> On 28 October 2014 19:47, Derek Andrew <derek.and...@usask.ca >> <mailto:derek.and...@usask.ca>> wrote: >> What is the alternative to the dial plan? Is everyone talking about getting >> rid of the statements like: >> exten => s,1, >> >> what is the alternative? >> >> 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. >> >> 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. >>
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. Before I jump into the details of my proposal, I’d like to clarify terms: * 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. * Removing something means it is gone from Asterisk. I made no proposals to remove anything, only to deprecate. 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. Now, on to what I originally proposed. 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. 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. I am not in favor of deprecating or removing extensions.conf at this time. However, I most certainly did propose to deprecate AMI and AGI. As protocols they have several significant drawbacks: * 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. * 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. * 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. * 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 * AMI and AGI were not invented with Unicode in mind. Internationalization is already important and will only become more so. * 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. 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. 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. 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. 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. 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. /BAK/ -- Ben Klang Principal/Technology Strategist, Mojo Lingo bkl...@mojolingo.com <mailto:bkl...@mojolingo.com> +1.404.475.4841 Mojo Lingo -- Voice applications that work like magic http://mojolingo.com <http://mojolingo.com/> Twitter: @MojoLingo
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
