<div dir="ltr"><div><div><div>The examples on github[1] use client libraries for both the Python and JavaScript examples. Client libraries abstract out some things for ease of use, such as namespacing events for a given instance (channel, playback, et cetera) but more importantly perform a lot of boilerplate that you would otherwise be responsible for.<br><br></div>In addition, a client library shields developers from a changing API to some degree. Both the Python and JavaScript libraries used in the examples generate their API from ARI json definitions of what ARI can do. This means that developers have access to the latest API on their target Asterisk server without having to modify their boilerplate code.<br><br></div>As they stand today, the libraries we use in the examples are very thin wrappers around ARI. Other than establishing a WebSocket connection and providing a means to handle Stasis events, they mostly construct HTTP requests for you and return objects from the responses. None of these conveniences have to do with the way ARI works specifically.<br><br></div><div>[2] does a very good job at laying out the basics of how ARI works but mostly does so with client libraries for the examples. One way to drive adoption is to provide examples in as many programming languages as possible so that users can be comfortable in their environments. A pull request on our github repository [1] is always welcome. I would encourage the use a client library there as well.<br></div><div><br></div><div><div><div><div><div><br>1 - <a href="https://github.com/asterisk/ari-examples">https://github.com/asterisk/ari-examples</a><br>2 - <a href="https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=29395573">https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=29395573</a><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 22, 2014 at 5:22 AM, Nir Simionovich <span dir="ltr"><<a href="mailto:nir.simionovich@gmail.com" target="_blank">nir.simionovich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>  I'm not sure if the dev list is the proper list of this, however, due to the fact that the issue at hand<br>revolves around documentation and proper usage, I think bringing it up here is a good place.</div><div><br></div><div>  So, during the past few days, I've been trying to implement the Dial application using ARI. So, <br>I'm aware I'm not the only one, but I'm the one trying to do it using PHPARI - naturally. </div><div><br></div><div>  In any case, I managed to write the functionality - reaching an issue where if I disconnect the <br>first bridge handled by the stasis app, it will kill all the other bridges as well. I was wondering why<br>that happens. I then realized that part of the my stasis loop implementation is just wrong, and it's<br>not because PHPARI is wrong, or ARI is wrong - it's wrong because it is a WebSocket client.</div><div><br></div><div>  A stasis application, at least as I understand it - is a websocket client - or consumer in that <br>respect. However, our consumer application is required to be able to handle multiple sessions,<br>so, it now needs to be stateful on one hand, and 'multi-threaded' on the other. The result is that<br>our 'client' application is actually a server in disguise. </div><div><br></div><div>  This is something that the ARI documentation and general usage concepts is missing - I think <br>that we need to make ARI more accessible by explaining the basic concepts better.</div><div><br></div><div>  Another thing, yesterday Scott and I were going through Matt's example of the "bridge_dial" ARI<br>application. The fact that the ari-py is autogenerated makes it really hard for a none-python (yours<br>truly) guy to follow along. Even Scott, who is fluent in Python had a bit of trouble looking through the <br>logic of the app, specifically when seeing that a certain event overloads an existing one - and some <br>other stuff that ari-py does. </div><div><br></div><div>  In other words, if we want to deprecate AGI/AMI at some point - or for a better term, get people to <br>use ARI extensively - we need better examples. I'm working on adding additional examples to PHPARI<br>for this, but we need simple, to the point, usage examples for ARI. For example, examples that don't<br>go about and do something funky in the background, so that people can truly learn from it. </div><div><br></div><div>  When I started with AGI and AMI, the one thing I liked was that I could use BASH. ARI isn't such a thing,<br>and a WebSocket library is mandatory. But giving some basic concepts using only that, would be <br>awesome.</div><div><br></div><div>  What do you think?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Nir </div></font></span></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a 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 href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><pre style="white-space:pre-wrap">Samuel Fortier-Galarneau
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  <a href="http://www.digium.com" target="_blank">www.digium.com</a>  & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></pre></pre></div></div>
</div>