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

[Daniel Jenkins]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131019/e330a62d/attachment.html>