[asterisk-dev] Asterisk 12 API improvements

[Dan Jenkins]

Hi All,

Thought I'd put some comments against parts of the wiki,

*We're going to start with fixing one of the most glaring problems with the
current APIs: add a stable identifier to
channels<https://issues.asterisk.org/jira/browse/ASTERISK-20725>,
and use that identifier consistently throughout AMI. This solves a big
problem for current AMI+AGI based applications. - **LOVE this!*

*Unfortunately, solving some of the larger problems would be very intrusive
with the current API's, and introduce a host of breaking changes. Some are
so fundamental, we would essentially be rewriting the interface. That's not
acceptable; the current API's aren't going anywhere anytime soon. *- *Is
there not scope to enhance these APIs? There was discussion a few weeks
back on this mailing list about enhancing the AMI to support JSON/XML
rather than key value return separated strings (After reading further down
there is a line saying "**AMI Event Structure - AMI events should be
generated into a key/value object pair instead of the printf-style string
formatting currently used. This would allow Stasis to reuse the existing
events.**" - Does this mean that the suggestion above needs to happen
anyway?)*
*
*
 *The **stasis-http** component will be built upon this message bus to
expose a RESTful API, also utilizing WebSockets for asynchronous
communication to the external applications.* - *Can you go into a bit more
detail about why this API would use Websockets? What kinds of scenarios do
you see someone interacting with Asterisk directly with Websockets, in an
API type of way? I wouldn't allow a browser to connect directly to Asterisk
for example, I would get it going through a middle server that connects to
Asterisk and it's sole purpose is to connect to hundreds of clients using
websockets. I think we have to be careful about wanting to make this new
API accessible for everyone but still keep Asterisk doing what it's good
at, I hope this makes sense... However, I can also see how connecting with
websockets from a server could be useful, but I think I'd rather keep a
RESTful interface, where you can tell Asterisk "for an event that you would
emit about x you need to send the data to uri y as an HTTP call" and let
the data be consumed that way.*

Even so, I love the fact that Stasis is happening - it's the best way to
get web developers using such a "toolkit" as it's put - if it's done right
it could open the doors to some amazing applications.

In terms of Authentication and Authorisation, I'd like to see more of an
effort behind this, with mechanisms to create tokens to be used rather than
user and pass in plain text or even the handshake system currently in
Asterisk, this is something that isn't a huge issue right now with
Asterisk's current APIs but if we're looking at HTTP first with stasis then
we should be thinking about how this would be best used within HTTP and
make sure it works for other implementations too.

In terms of encryption, shouldn't this be down to the libraries off of
stasis? So stasis-http would take care of encryption within it, as
different protocols have different forms of encryption which is relevant
those those protocols? Is this the plan?

I also agree with Olle on the granularity of permissions of users within
this API, but for a different reason, the AMI has basic granularity in
terms of what it's able to do, which is used enormously, why wouldn't you
do something similar within this new API system?

I'm sure we'll have to add to that high level list of summary features, as
I'm sure we'll end up thinking of more solutions that would be perfect for
this type of interface, I'm interested to see what other tasks other people
think could be achieved using such an API

Let me know if I've misinterpreted anything in the wiki,

Dan

-- 
Dan Jenkins - Senior Web Developer
email: dan.jenkins at holidayextras.com
twitter: dan_jenkins <http://twitter.com/dan_jenkins>
linkedin: jenkinsdaniel <http://www.linkedin.com/in/jenkinsdaniel>
skype: d-jenkins
blog: www.dan-jenkins.co.uk
about.me: about.me/dan_jenkins



On 27 November 2012 05:16, David M. Lee <dlee at digium.com> wrote:

> Greetings all!
>
> I hope that everyone stateside enjoyed their Thanksgiving holiday. For
> everyone else, I hope you somehow managed to enjoy yourselves without
> massive amounts of turkey and various side dishes.
>
> Now that I'm back to work, I'd like to kick off an endeavor that I
> know several folks on the -dev list are interested in: improving the
> API's for Asterisk 12.
>
> I've just created a project page for the effort:
> https://wiki.asterisk.org/wiki/x/CoZHAQ
>
> I started writing a short summary of what we see happening for this
> effort, but that turned into a giant wall of text. Rather than burden
> your email with a crazy long email, I added some background and
> rationale to the 'Project Overview' section of the project page.
>
> I have some further ideas about the overall design, and specifics of
> the API itself. But rather than get too far ahead of ourselves, let's
> get some feedback on the requirements and overview of what we want to
> do.
>
> Thoughts?
> --
> 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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121201/18586cae/attachment-0001.htm>