[asterisk-app-dev] Death to /dial
Paul Belanger
paul.belanger at polybeacon.com
Tue Oct 15 11:09:31 CDT 2013
On 13-10-15 11:57 AM, David M. Lee wrote:
> In ARI, there's a convenience operations /channels/{id}/dial[1], which
> was provided as a simple way to dial and bridge in a single operation.
> I propose that we KILL IT DEAD. Right now. Before it's too late.
>
> Firstly, we already have a method for originating new channels: POST
> /channels. Having two operations that effectively do the same thing is
> evidence of silliness.
>
Well said, I am all in favor of removing redundant stuff from the ARI.
> Secondly, as we see folks discussing how they think about ARI, it's
> not really a great fit. People love the idea that they can create
> their own bridges, and freely move channels into and out of them. The
> implicit bridge created in the dial operation gets in the way of that.
>
> There is also a lot of hidden complexity that I believe will get
> exposed over time. As evidence, I present to you: The Dial dialplan
> application[2]. The number and combination of options on Dial are
> dizzying. All the possible scenarios of handling what might happen on
> the channel you have, the outgoing dial and the bridge combine into a
> big mess.
>
> Dealing with each of these individually in your application, however,
> is much cleaner. It gives the application developer more control over
> the process, and simplifies the interface.
>
> The one thing that we can think of that would be missing if we removed
> the /dial operation would be the ability to indicate ringing to the
> dialing channel. But I heard a rumor that someone might have a patch
> for this in the works (/me glances at file).
>
> So, thoughts? If we can provide the underlying originate, bridge and
> indicate operations that /dial is doing for you, is there any
> compelling reason to keep it around?
>
> [1]: https://wiki.asterisk.org/wiki/x/mIBbAQ#Asterisk12ChannelsRESTAPI-dial
> [2]: https://wiki.asterisk.org/wiki/x/HwGUAQ
>
So my logic is simple, if app_foo.c exists, it likely shouldn't live
within ARI. And I think /dial is one of those functions that could
quickly spiral out of control with additional parameters.
As long as we expose a way to build app_dial on top of ARI, lets do that.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger
More information about the asterisk-app-dev
mailing list