[asterisk-app-dev] How do third partymoduledevelopersexposetheir resources via asterisk ARI?

[Jared Smith]

On Wed, Oct 23, 2013 at 10:37 AM, Paul Albrecht <palbrecht at glccom.com>wrote:

> Let's say, for example, I want to write my own application for
> conferencing. Today I can write a module to do that because asterisk
> provides interfaces to register a dial plan application, extend asterisk
> commands, and emit new events. With my new dial plan application which
> supports conferencing actions/events I can control callers with a script
> written in my favorite programming language which receives events, like
> dtmf, from my application, taking appropriate actions to run my conferences.
>

Sure, anything is possible -- it's just code.  But writing a new
conferencing application in C code is much harder (and fraught with danger
with regards to memory management, locking, embedding another scripting
language) than writing such an application using ARI.  In short, ARI
exposes some of the basic building blocks (answering calls/playing
sounds/recording audio/dealing with channel bridges/playing indications),
and leaves you to build the logic around those blocks in an external
language of your choice.


> Given all this I don't see how you can possibly maintain ARI/Stasis is
> *NOT* reinventing the AMI wheel. In fact, seems like it's a step backwards
> because it wasn't designed for third party developers.
>

Sure, there's going to be some overlap between what you can do with ARI and
what you can do with AMI.  Take, for example, getting information about a
particular channel in use.  In AMI, you'd issue the "Status" command.  In
ARI, you'd call the /ari/channels/{ChannelId} resource.  It's obvious that
when you're dealing with basic channel operations, there is going to be
some duplication of effort.  The point that you don't seem to be getting is
that ARI is mostly about an external application controlling the logic of a
call *on a (mostly) channel-oriented basis*.  AMI, on the other hand, is
mostly about an external application controlling an Asterisk system *on a
(mostly) non-channel-oriented basis*.   As I attempted to explain earlier,
the vision of ARI is to have it be much more of a replacement for Async AGI
and ExternalIVR than it is for it to be an AMI replacement.

I don't know how you can say it wasn't designed for third-party developers
-- that's *exactly* who it was designed for.  If you had the choice of
writing a new conferencing app (to use your example) or queueing app or
voicemail app, would you really prefer to write it in C?  I know I
wouldn't.  I'd prefer to write it in Python or NodeJS or, heaven forbid,
Perl.  One of the prominent reasons for building ARI was to help get
Asterisk out of the business of having one canonical way of handing
voicemail, for example, and instead allow integrators and end users to
script the logic to fit their needs, in something easier than C code.
Modern developers are obviously more likely to get involved in writing
their own logic if they can do it using something like REST and websockets.


> Seems like ARI/stasis is a solution to a non-problem architected by people
> who don't understand how asterisk works or how asterisk is used by third
> party developers.
>

That's a pretty bold statement, and one which probably doesn't even justify
a response, but I'll respond anyway.  If you had actually looked to see who
has done the development work on ARI, and who has helped to make it better,
you'd hopefully realize that they *do* know how Asterisk works, as they're
some of the principle developers of Asteris, and they *do* know how
Asterisk is used by third-party developers.  Just because you haven't
caught the vision of ARI doesn't mean it's not a useful tool for those of
us who choose to use it, and it certainly doesn't justify attacking the
people who wrote ARI.

--
Jared Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131023/035d1f0e/attachment.html>