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.
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
--
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131015/92c4c79f/attachment.html>
