<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
I've been reading recent emails on the developers list and just
wanted to add my 2 cents:<br>
<br>
While the AGI approach was never useful for my needs, I recently
finished 2 years of almost straight development time to develop a
full-fledged call answering solution and I would be VERY annoyed
(to say the least) if AMI was deprecated! While many people do
web programming due to it's simplicity, I find a C-based program
is ALWAYS more elegant. As such, AMI was the ONLY interface to
Asterisk that was useful to building the interface we needed (keep
in mind that web socket support for C-based applications is VERY
poor! We've researched it for another application & found
that we were not able to do what we needed it for!) & we are
just starting to enjoy the benefits of the work. I'm not saying
web development doesn't have it's merits, as some applications
demand it, but in my opinion a C-based program is better catered
for someone using it 24-7. So please, if you want to deprecate
something, don't do so to AMI!<br>
<br>
Note: While I'd have no problem myself with deprecating the
dial-plan (actually, if I didn't have to deal with it at all &
the complexities of requiring a channel to be in async AGI mode
before issuing an AMI command to it, then that would have very
much simplified my development!), I can understand why a lot of
people would be adverse to such a change.<br>
<br>
In summary, I think having different ways of controlling Asterisk
are required, depending on the application:<br>
<br>
- AMI for those wishing to interface with a more elegant C-based
application.<br>
- Something like the dial plan for those wishing to use Asterisk
as is, without developing an external interface.<br>
- ARI or AGI for web-based solutions (hence why deprecating AGI
probably wouldn't be negative, being that they are 2 solutions to
the same ends..but DEFINITELY keep the AMI as it's purpose/use is
different).<br>
<br>
Whatever you do, please keep the AMI interface!<br>
<br>
Thank You!<br>
<br>
<br>
On 10/28/2014 06:03 PM, Ben Langfeld wrote:<br>
</div>
<blockquote
cite="mid:CAAyX+KGSxxOvQ7fkjybNwFwgrKtz8pBwCP7nP_U3nzBpfP8JMQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 28 October 2014 19:47, Derek
Andrew <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Derek.Andrew@usask.ca" target="_blank">Derek.Andrew@usask.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div dir="ltr">
<div class="gmail_extra">What is the alternative to the
dial plan? Is everyone talking about getting rid of
the statements like:<br>
exten => s,1,<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">what is the alternative? <br>
</div>
</div>
</blockquote>
<div><br>
Remote applications based on APIs like ARI. This is the
start of the discussion, and please remember that nothing
has been decided or even presented as a robust plan yet.
This is brain-storming.</div>
<div><br>
</div>
<div>Additionally, note that the original proposal was to
deprecate AMI/AGI in favour of ARI once it is feature
complete with those protocols; an entirely lesser change
than the removal of the dialplan in its entirety.</div>
<div> </div>
<blockquote class="gmail_quote">
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a
moz-do-not-send="true" href="http://www.api-digital.com"
target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a moz-do-not-send="true"
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>