[asterisk-dev] Adding new ARI for application execute
Sung-tae Kim
pchero21 at gmail.com
Thu Apr 4 03:35:47 CDT 2019
2019년 4월 4일 (목) 오전 12:07, Matt Fredrickson <creslin at digium.com>님이 작성:
> On Tue, Apr 2, 2019 at 6:05 PM Kevin Harwell <kharwell at digium.com> wrote:
> >
> > On Tue, Apr 2, 2019 at 4:01 PM Sungtae Kim <pchero21 at gmail.com> wrote:
> >>
> >> So, here's some API draft.
> >>
> >> I will introduce 2 new ARI requests and 1 ARI event.
> >
> >
> > ARI is meant to be an alternative to diaplan applications, and not act
> as a layer on top of them. Which I feel is the direction this idea is
> heading towards. For instance, ARI is not meant to overlay app_queue, but
> allow a developer to create their own queue app that interfaces with
> Asterisk through ARI. I feel like doing things as proposed violates the
> underlying design and goal of ARI. However, see my other response. Maybe
> this can be done without changes to the ARI definitions and in a way that
> does not undermine the design of ARI.
>
> That's kind of how I feel about it as well. It's my understanding
> ARI's original intention was to provide a REST API that allows you to
> build detailed, channel centric Asterisk applications (such as the
> app_queue replacement) without having to resort to writing C code. A
> lot of what Sung is trying to do sounds like it would more
> appropriately fit as AMI type actions instead, IMHO.
>
Yes, with AMI/AGI, we can do anything! :) But ARI can make this so simple!
I like KISS!!
> All that being said, I think sometimes we limit the potential of ideas
> based on solely preconceived notions. It's possible that the original
> intentions of ARI could be transcended in appropriate ways. On the
> other hand, and as mentioned by Josh and others, there is potential
> danger in permitting arbitrary dialplan application execution that
> could come back and haunt us. If you were to ask me my honest
> opinion, I feel a lot of what Sung wants to do lies outside of ARI's
> original design.
>
Yes, I agree with that I'm asking too many things to the ARI, even it was
not
designed for that.
I'm just thought it would be good to have this feature cause it looks
possible.
And it was so regretful to don't have this feature - this is why I started
this talk. :)
As I said before, I don't want to break down the Asterisk at all. So, I
would start this with small things
as Joshua said, if Digium team agreed. :)
>
> Just my .02.
>
> Matthew Fredrickson
>
> >
> >>
> >> <snip>
> >
> >
> > --
> > Kevin Harwell
> > Digium - A Sangoma Company | Senior Software Developer
> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> > Check us out at: https://digium.com & https://asterisk.org
> > --
> > _____________________________________________________________________
> > -- 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
>
>
>
> --
> Matthew Fredrickson
> Digium - A Sangoma Company | Asterisk Project Lead
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190404/453c6624/attachment.html>
More information about the asterisk-dev
mailing list