Death to /dial

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux