[asterisk-dev] AstriDevCon - PineMango

[Brian Degenhardt]

Martin Smith wrote:
> Hi all,
> 
>> Brian Degenhardt wrote:
>>
>> 2) Give Asterisk a flexible programming API such that this 
>> functionality
>> can be done outside of Asterisk in a development framework.  Apache +
>> Rails is a great example of this.  Does Rails diminish the 
>> importance of
>> Apache?  It does a bit, but imagine how diminished Apache would be if
>> you couldn't use Rails with it because it didn't expose 
>> enough of an API.
> 
> I'd love to see Manager become that API. I realize this is fraught with
> performance issues and probably many other considerations. But I'd love
> to see something sockets based. +1 that security is important for
> sockets based designs.

To answer this, I need to refer to Nir's diagram (because it's prettier
than the pbwiki one):

http://www.simionovich.com/wp-content/uploads/2008/10/image2_diagram1.jpg

The first things we need to build in Asterisk is the C APIs that connect
you to the core.  These include the pbx switch interface (which already
exists), events (mostly there), data_get (prototyped, might need more
work), data_put, hooks, and call_api.

Once you've built that, then you can write your API modules that have
access to all of the guts of Asterisk to do whatever they want (that's
the tan layer of the diagram).  At this point, the current manager
implementation can be rewritten to use data_get, events, and call_api
and work almost exactly how it does today.

You could even do a manager++ which is today's functionality, but allow
access to more hooks, more events, and more data_get stuff.

That being said, I think that we can do much better than manager as an
API interface.  That's the goal for res_api, which hasn't had much
design finalized, and is very ambitious.

--------------- detailed design ramblings ensue ----------------------

The first aspect of res_api is the actual API itself.  Putting aside the
calling conventions and data encoding, what does the API look like?
Manager is pretty much a direct window into the guts of asterisk, and
this poses a problem because when the guts change, Manager's API breaks.
 If we instead design the API as a loose abstraction we both a) make it
more usable, and b) insulate it from changes to the blue boxes below.
I've been reading up on the various telephony APIs that already exist to
see how people do this: JTAPI, CSTA, etc.  Hopefully we can combine
lessons from them in a way that doesn't sacrifice the power of
asterisk's internals.

Ok, now that we've designed the perfect API (wasn't that easy?), how
does one use it?  One of the things we floated is perhaps a pluggable
inteface to res_api that deals with connections and encoding.  Me
personally, I'm sorta partial to a socket that uses a binary data
encoding method like ASN.1 or Google Protocol Buffers.  But why not have
another interface that does XML over XMPP?  Shared memory is another
idea which may provide a lot of speed.  Hell, for the masochists we
could do a textual socket interface that's encoded like manager
(although we'd have to figure out how to do deep hierarchical data).
This pluggable-transport idea may be too ambitious, but it's something
to consider.

cheers
-bmd