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

[Paul Albrecht]

On Oct 23, 2014, at 1:58 PM, Kevin Larsen <kevin.larsen at pioneerballoon.com> wrote:

> > From: Paul Albrecht <palbrecht at glccom.com> 
> 
> > Seems like now is as good a time as any to raise these issues, in 
> > fact, sooner is better than later because once developers start down
> > a path it’s very difficult to get them change their minds no matter 
> > how much sense it makes. The fact that developers are even 
> > considering taking away user functionality like the dial plan is in 
> > of itself a very serious problem because it demonstrates they don’t 
> > see Asterisk from the user perspective. 
> 
> > Don’t object to extending the Asterisk user interface or changing 
> > Asterisk internals. Do object to is taking away functionality that 
> > users expect, are familiar with, and has made the Asterisk project successful. 
> 
> > Then your experience is atypical. Asterisk has been unstable for 
> > several years as developers have continually shoveled new features 
> > into the code base over several releases. That’s not necessary 
> > objectionable, it’s even to be expected; however, at some point 
> > developers need to turn their attention to less glamorous less 
> > exciting things like stability and performance. 
> 
> I don't think anyone is objecting to you bringing this up, as it has been mentioned at the dev con. Perhaps it is just that the tone doesn't come across properly in an email, but you are coming across as confrontational and alarmist and it seems to be setting people on edge. Matt has already chimed in that he doesn't see how it would be possible to deprecate the dial plan at this time and even if it were possible, the process would take on the order of years, giving you plenty of time to enact any contingency plans you might need. Scott G. from Digium even posited that if it were to be removed from the core, it would likely end up as a loadable module so that it wouldn't burden those who don't need it and could be loaded for those who do. 
> 

When Matt says deprecating the dial plan would be difficult and would take a long time it seems to me he’s being evasive and misleading. He doesn’t say it’s never going to happen and he doesn’t share whatever he thinks the Asterisk vision actually is which he should presumably be aware of since he is the Asterisk engineering manager.

As for Scott’s suggestion, I don’t see how you can have it both ways: on the one hand ARI can’t work in an environment supporting AGI/AMI and the dial plan, and on the other you can support AGI/AMI in an optional module. It’s just not believable. If you’re not convinced, run menuconfig and look through the applications and functions sections. All of this stuff would have to change and you think that at the end of that process the dial plan would survive? I don’t think so.

> These developers do not exist in a vacuum, nor do they have total control over where Asterisk goes. Influence, sure, but there is still a corporate structure out there that finds it necessary to be customer oriented. They would have to be monumentally stupid (something which I haven't seen previous evidence of) to kill off the dial plan without providing a path forward for those who depend on it. Furthermore, even if they did pull a stunt so bad as to alienate half their users, the open source code would be forked so fast as to make your head spin or people would migrate to other similar packages (Freeswitch comes to mind). Digium sells their own PBX hardware that I am sure depends on these technologies that you are afraid will go away. They have direct skin in this game too. 
> 

Totally get why Ben Klang thinks everyone should use adhearsion and that all the resources of the Asterisk community should be devoted to his project. But of course everyone thinks their project is the most important project in the world. What I don’t get is why one project or framework is deemed to be so important that is trumps everyone else in the Asterisk community.

> I would be interested to know just how atypical my experience is. I have found that on my 1.6 systems I would have random crashes over time. After upgrading over multiple sites, my 11.x systems have been rock solid for the most part. I did have a case where I did a store and forward of a fax that if I tried to forward the fax and it had no file to forward would cause a crash, but other than that, I haven't seen any problems in normal day to day usage. I always thought that the general consensus was that the 11.x series was quite a bit more stable than the older versions. 
> 

Wouldn’t use the 1.6 release as a basis of comparison as that release was regarded as DOA by most folks. A better example would be Asterisk 1.4. We use it because it’s stable, we don’t need any of the new features and definitely want to avoid the performance degradation in the later releases.

Having said that, Asterisk 1.6 was an interesting release because that’s when “async agi” was introduced and where Asterisk starting going off the rails. “aysnc agi” is a kludge and makes no sense in dial plan based applications. Of course, once this threshold was passed ARI made sense, that is, if you can get your head around “async agi” then yes ARI too makes sense.

Lastly, seems to me that if it is the consensus of developers that they can’t get ARI to work in an environment which supports AGI/AMI and the dial plan then the “async agi” ARI experiment has failed and further development should be discontinued.


> Kevin Larsen -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141024/6b089213/attachment.html>