[asterisk-dev] AstriDevCon - PineMango

[BJ Weschke]

Brian Degenhardt wrote:
> 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.
>
>   
 I give a big +1 to the pluggable transport idea, and that's one of those things where if it isn't done from the start, I don't really believe that it every will be because the task to migrate will be too great.

--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/