<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="">Il giorno Oct 30, 2014, alle ore 4:57 PM, Paul Albrecht <<a href="mailto:palbrecht@glccom.com" class="">palbrecht@glccom.com</a>> ha scritto:<br class=""><div><blockquote type="cite" class=""><br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">On Oct 29, 2014, at 2:45 PM, Ben Klang <<a href="mailto:bklang@mojolingo.com" class="">bklang@mojolingo.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div><br class=""></div><div>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: <a href="https://en.wikipedia.org/wiki/Deprecation" class="">https://en.wikipedia.org/wiki/Deprecation</a>.  Perhaps I just should have linked to that originally, as their explanation is even better than my own.</div><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> <br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Now, on to what I originally proposed...</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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? </div></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">It is my opinion that while AGI and AMI are probably individually fixable, doing so would cause backward-incompatible changes…</div></div></blockquote><br class=""></div><div class="">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? </div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>/BAK/</div><div><div style="orphans: 2; widows: 2;" class=""><div class="">-- </div><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 style="orphans: 2; widows: 2;" class="">Twitter: @MojoLingo</div></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""></div></div>-- <br class="">_____________________________________________________________________<br class="">-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" class="">http://www.api-digital.com</a> --<br class=""><br class="">asterisk-dev mailing list<br class="">To UNSUBSCRIBE or update options visit:<br class="">   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" class="">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></div></blockquote></div><br class=""></body></html>