> -----Original Message----- > From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev- > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Michael L. Young > Sent: 17 January 2014 16:02 > To: Asterisk Application Development discussion > Subject: Re: Questions concerning communicating with an > ARI app/module from an external application > > ----- Original Message ----- > > From: "Ben Merrills" <b.merrills@xxxxxxxxxxxxxxxx> > > To: "Asterisk Application Development discussion" > > <asterisk-app-dev@xxxxxxxxxxxxxxxx> > > Sent: Friday, January 17, 2014 5:26:45 AM > > Subject: Re: Questions concerning communicating > > with an ARI app/module from an external application > > > > > On 16/01/14 22:58, Daniel Jenkins wrote: > > > > What a few of us in IRC are suggesting is for Asterisk to act as a > > > > proxy in a sense when it comes to talking to an ARI application. > > > > And > > > > for that proxy to enforce standards. > > > > > Alistair Cunningham wrote: > > > Is there any reason that this proxy has to reside within Asterisk? > > > How about > > > having an external ARI proxy/multiplexor/routing daemon that > > > connects to Asterisk ARI, any configured ARI applications (or lets > > > them connect to it), and any other desired IPC systems such as > > > ZeroMQ? That would then leave Asterisk to get on with what it's good > > > at, which is processing calls. > > > > I think that, based on the fact that AMI isn't being depreciated, why > > would we not include it in a mechanism for communicating between > > asterisk applications and 3rd party applications. Currently if I want > > to talk to app_queue I can use the Actions and Events that app_queue > > exposes. Why would you remove that ability? > > I have had to re-read a couple of times Dan's email and yours and I think I am > starting to understand what you guys are envisioning. > > But, just to be sure, are you guys talking about an App ontop of an App? You > want an App to communicate with an ARI App with Asterisk in the middle? > > > Why should people have to use "another standard" just to commutate > > with something that, to them is no different from app_queue. ARI > > should be a complimentary API, not a thorn in 3rd party dev's side. > > They may be totally unaware it's an ARI implementation, and to be > > honest, they shouldn't have to care. > > I am not sure how ARI would be a "thorn in 3rd party dev's side". It is a tool > that one can choose to use. Every tool has a purpose. It comes down to > using the right tool for the right job. But if it creates more work, then it's not really helping. However I don't want this to turn into some argument about ARI, the simple fact is I think ARI is great! It'll mean people like me, with no C skills at all can write first class citizen applications for Asterisk. By Applications, I of course mean app_* e.g. app_queue etc. Which until now has been outside of our abilities. If you're a C# dev, like me, you're confined to the likes of AGI and AMI. > > > AMI Actions could be mapped to an ARI Event message, and ARI could > > push messages to AMI. Yes, you're constrained by the format of AMI > > actions and messages, but you retain backwards compatibility in the > > process. > > Here it sounds like you want the reverse. An AMI app to communicate with > an ARI app? If someone is using AMI, why would they need ARI? Well, let's look at the example we harp back to each time, app_queue. People (like me and lots of others) use AMI to control app_queue in real-time. We can add queue members, get information about queues and gather information via events. In fact, a lot of work has been put into applications that sit on peoples desktops that communicate with app_queue via AMI. Wallboards, management interfaces etc etc. So to say "why x when you have y" seems less than well thought out. > > > You could have a way of registering AMI Actions from ARI, that exist > > within a specific application. Then have a way of executing those > > Actions from the AMI. For example: > > > > ARI -> POST -> Register Action "AddQueue" { json description } AMI -> > > AddQueue [params] -> ARI Event Message -> ARI Registered Action Event > > > > ARI -> POST -> AMI Event "event name" { json description } -> AMI > > Event > > > > (excuse my very lame flow above) > > This appears that you want to create dynamic AMI events from ARI. Why > would we be using Asterisk in this fashion? This just doesn't seem right. > This functionality already exists in AMI, it's called UserEvent. We just want to take that to the next logical step. If you replace app_queue with ARI. With the current propositions, all of a sudden AMI is no longer able to deal with queue events or interact with queues at all. Why? There's no need to remove that functionality and force devs to use "yet another" protocol to interact with app_*. > I agree with Alistair. I feel that this does not belong in Asterisk. > > Asterisk is a toolkit. It allows you to use the right tool for the right job. I agree, asterisk is a toolkit, and an excellent one. However we need to focus on how people use that toolkit. Simply dismissing the fact that lots of developers use AMI to interact with asterisk, especially things like queues would be a mistake in my (humble) opinion. > > Maybe I am just not quite getting the idea that is being proposed and why it > should be in Asterisk. > > Michael _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
