[asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)

[Ben Klang]

Il giorno Oct 30, 2014, alle ore 4:57 PM, Paul Albrecht <palbrecht at glccom.com> ha scritto:
> 
> On Oct 29, 2014, at 2:45 PM, Ben Klang <bklang at mojolingo.com <mailto:bklang at mojolingo.com>> wrote:
> 
>> 
>>> On 10/28/2014 06:03 PM, Ben Langfeld wrote:
>>>> On 28 October 2014 19:47, Derek Andrew <Derek.Andrew at usask.ca <mailto:Derek.Andrew at 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...
>> 
> 
> It’s intellectually dishonest to redefine the terms of an argument to presuppose your own conclusion. If you don’t intend to use the term “deprecate” as it is commonly understood by software developers and users than you should avoid the use of the term “deprecate” so that others clearly understand your argument. If you really mean “deprecate” as commonly understood by software developers and users then you should be prepared to defend that proposition.

I had thought that the term “deprecate” was already understood to be the definition I gave, but earlier posts on the mailing list seemed to indicate confusion. My definition mirrors the Wikipedia definition: https://en.wikipedia.org/wiki/Deprecation <https://en.wikipedia.org/wiki/Deprecation>.  Perhaps I just should have linked to that originally, as their explanation is even better than my own.

In any event, what we are talking about is the deprecation as I defined it. If you prefer another word for it, I’m fine with that too.  I just want to be clear that my proposal is to discourage use of AMI/AGI in new projects, but not to immediately remove it.

>  
>> Now, on to what I originally proposed...
>> 
> 
> It’s clear from the title of the agenda item what was proposed. You proposed deprecating AMI/AGI and that entails deprecating the dial plan. The fact that deprecating the dial plan is now on the table is a direct consequence of your proposal. This is reflected in both comments made at AstiCon and Matt’s summary of  Astricon on the development list. You can’t have it both ways. You want to deprecate dial plan or not. Which is it? 

Actually, AMI/AGI and Dialplan are separate.  You can disable AMI and you can unload res_agi.so. Dialplan/extensions.conf continue to work just fine.  Certainly AMI/AGI make use of Dialplan, but deprecating AMI/AGI doesn’t mean you have to deprecate Dialplan.

> 
>> It is my opinion that while AGI and AMI are probably individually fixable, doing so would cause backward-incompatible changes…
> 
> Deprecating the dial plan and AGI/AMI is incompatible going forward. What is supposed to happen? Are users supposed to throw away there applications whenever ARI/Stasis is feature complete? Is ARI/Stasis really any easier to use than the dial plan? Are we all supposed to use Adhearsion? 
> 

You’re certainly welcome to use Adhearsion :) For what it’s worth, Adhearsion will continue to support AMI/AGI because we have to until ARI is feature-complete.  For Adhearsion users, the transition to ARI should be seamless because that’s one of the things that the framework promises: to paper over the idiosyncrasies of the underlying protocols.

If you don’t want to use Adhearsion, I’d recommend you look at ARI for developing new projects.  There are libraries in many languages that make it easy to use. It’s got a great start and will only improve as people continue to use it and develop additional features.  Today, it is not yet a replacement for AMI/AGI, but I’m very optimistic that it will be in the near future.

I suspect that I’m not convincing to you, and that you want to continue using AMI/AGI. That’s fine, I’m not telling you to throw out any code.  I think Asterisk’s historical policy toward backward compatibility and removing features speaks for itself.  Rather than continue to debate the semantics of my proposal, I’d like to continue the discussion on how we can improve ARI and improve the state of the world for all Asterisk developers in the years to come.

/BAK/
-- 
Ben Klang
Principal/Technology Strategist, Mojo Lingo
bklang at mojolingo.com <mailto:bklang at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141030/8cbc01fe/attachment-0001.html>