[asterisk-app-dev] How do third partymoduledevelopersexposetheir resources via asterisk ARI?

[Paul Albrecht]

On Oct 19, 2013, at 7:55 AM, Daniel Jenkins <dan.jenkins88 at gmail.com> wrote:

> 
> 
> 
> On Fri, Oct 18, 2013 at 5:48 PM, Paul Albrecht <palbrecht at glccom.com> wrote:
> 
> On Oct 17, 2013, at 2:25 PM, Daniel Jenkins <dan.jenkins88 at gmail.com> wrote:
> 
> > I'm not sure if I've missed something here or not,
> >
> > I took Paul A's question to mean something completely different...
> >
> > Going on the proviso of say replacing app_queue with an application using the ARI, we would need to have a way of emitting an event like "QueueAdd" or whatever via the AMI so that people just using Asterisk and it's built in queueing mechanism (they don't care its a separate module via the ARI)
> >
> > These people still want QueueAdd events via the AMI and so the module being written (in this instance, app_queue) would have to tell asterisk to emit that from the AMI.
> >
> > It all goes back to two different "purposes" of the ARI, replacing built in applications with apps written using the ARI (which may be bundled with packaged asterisk at some point), and writing custom apps that are completely standalone....
> >
> > Paul A, if this isn't what you meant, then I've completely misunderstood, but that's what I took it as….
> 
> I didn't reply to your post yesterday because I didn't understand your question. If you're asking me whether I expect to receive AMI events and send AMI actions over the asterisk web socket I'm supposed to use to control/monitor asterisk, then the answer would be obviously, yes.
> 
> I don't think this is "obvious" at all Paul, and that's why I was asking you a question. This mailing list is for help/discussion; this is a great community, without that community there would be no product for you to use so please treat people a little better when replying. The ARI is brand new, Asterisk 12 is in BETA and is not a finished product; which is why there's these awesome discussions happening on this mailing list, giving people a chance to have their input into the final product.
> 
> 1. You want to be able to create an application (using the ARI - so completely external to Asterisk) which deals with doing X and when X happens, you want to tell asterisk to emit an event of say DoneXFoo via the AMI so that other applications built on top of Asterisk can use said event? And you want to be able to do this by sending an HTTP request to Asterisk like POST /ari/event/ with a JSON payload in the body of details of what you want to send? Is this where you're going with this? As I don't believe that's what others have taken from this conversation.
> 
> 2. You also want to register certain AMI actions with Asterisk as part of your application registration, so that a user of Asterisk and the AMI can send an AMI action called DoXFoo with some data, which will get sent via the websocket to your application, so your application can act upon it?
> 

Let's say, for example, I want to write my own application for conferencing. Today I can write a module to do that because asterisk provides interfaces to register a dial plan application, extend asterisk commands, and emit new events. With my new dial plan application which supports conferencing actions/events I can control callers with a script written in my favorite programming language which receives events, like dtmf, from my application, taking appropriate actions to run my conferences.

Given all this I don't see how you can possibly maintain ARI/Stasis is *NOT* reinventing the AMI wheel. In fact, seems like it's a step backwards because it wasn't designed for third party developers.

Seems like ARI/stasis is a solution to a non-problem architected by people who don't understand how asterisk works or how asterisk is used by third party developers.

> I'm just trying to extract what you really want so we're all on the same page; if this is what you're after, let us know, I completely see where you're coming from, if you're not after this I'll be raising the issue myself. If this isn't what you're asking for, please try and explain a little more so we can all work on a solution together.
> 
> We want to make sure the ARI does (to a certain extent) what people want it to do, so that it's a huge success when Asterisk 12 IS released as a final product, which will really be Asterisk 13 by the sounds of things, due to the release policy put in place for 12.
> 
> Dan
>  
> 
> >
> > Dan
> >
> >
> > _______________________________________________
> > asterisk-app-dev mailing list
> > asterisk-app-dev at lists.digium.com
> > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> 
> 
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> 
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131023/e0b65aa2/attachment.html>