Now, this is why I love Open Source - opinions, thoughts and most importantly, acceptance.
I can totally see where the general idea is going here, and that is what we all agreed during AstriDevCon this year. On Thu, Dec 18, 2014 at 6:31 PM, Leif Madsen <[email protected]> wrote: > > On 18 December 2014 at 11:07, Paul Belanger <[email protected]> > wrote: > >> On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich >> <[email protected]> wrote: >> > New question: Do we want to enable legacy features inside ARI? >> > >> New answer: I don't believe so. >> >> I think this issue / question is the hardest thing to understand about >> ARI. There really isn't any sort of link to existing Asterisk >> application or features; not yet any ways. Somebody has to build it >> again a top of ARI. >> >> When I first dreamed of using ARI I was looking at it from a >> configuration management tool mindset. Oh, I could create a new peer >> in chan_sip over HTTP or let me reconfigure features.conf using ARI. >> However, as I started playing with it more I found that was not what >> it did. And, changing it to do something like that doesn't feel like >> the right approach. >> >> Now, that being said. Creating some sort of interface to control >> sorcery objects, now that would be cool. Having sorcery connect to >> redis and change key / values directly in redis for sip peers would be >> hotness. However, I'm not sure I would want to have Asterisk serve up >> that interface directly. Feels more like an external application >> would serve up the REST interface into redis, allowing the user to >> change key/pairs. >> >> I also believe, until there are some standard ARI libraries / >> application (for example app_dial replacement). It will feel like a >> large task to build anything in ARI, because some of the core >> application basically need to be written from scratch. And I think >> this is the main reason people are slow to move to ARI or fearful from >> dropping the dialplan. Because doing: >> >> exten => s,1,NoOp() >> same => n,Dial(SIP/[email protected]) >> >> is a lot easier then origination a channel over ARI, creating bridges >> and playing any tones needed using ARI. Easier might not be the right >> work, more steps required is. >> > > I also agree that we do not want to start making ARI start talking to > legacy applications. > > As discussed at AstriDevCon, the push is really to start making Asterisk a > media communications platform. The way to do that is to move away from the > dialplan centric driven applications and to move to a decentralized model > of applications and business logic being separated from Asterisk, and > essentially making Asterisk much dumber in terms of the actual business > logic and routing logic, and making it a lean mean media communications > machine. The way forward sometimes is to stop looking back. > > Currently both AMI and AGI are still happily co-existant in Asterisk, and > should be considered the defacto interface to traditional methods of > writing Asterisk business logic (dialplan, etc). When flipping to ARI, it > is a different mind set that does take some time to get around. Much like > Paul I had my own preconceived notions about what ARI was and was initially > disappointed it didn't match what I thought it should have been. However > over the last few months of watching what Paul has been doing along with > some small side POC stuff to better understand what ARI is intended for, it > definitely has become a lot clearer. > > At the most basic levels, ARI to me is a bridge control interface that > allows you to hook channels together while not worrying about transcoding, > media characteristics etc. You have two or more channels that may or may > not speak the same language, and your external applications stick them > together, and Asterisk acts as the universal translator for those channels. > By writing all your business logic and controls outside of Asterisk, it > makes the API much simpler to interoperate with, and allows great scaling > possibilities. > > Admittedly I'm still a bit naive on a lot of the ARI front, but one thing > my gut tells me, is it is a new interface, and should not be confused as a > replacement to the legacy (term used loosely) methods of building Asterisk > systems. This is one of those situations that I feel avoiding legacy and > backwards compatibility with the traditional methods is going to really > open up a better realm of possibilities with ARI. If someone truly just > needs an HTTP based interface for controlling dialplan and such, I feel a > translation application (library) should just be written for AMI and AGI > that permits that and has that goal. Overloading what ARI is supposed to be > doing is a step backwards in my opinion. > > -- > Leif "The Dialplan Is Dead" Madsen > > -- > _____________________________________________________________________ > -- 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 >
-- _____________________________________________________________________ -- 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
