[asterisk-users] Higher level API on top of AMI and AGI (was Re: "Real" API for Perl?)

[Lee Jenkins]

Stefan Reuter wrote:
> Lee Jenkins wrote:
>> I thought that the OP was asking for something to perl what Asterisk-Java does 
>> for java coders.  I would definitely consider Asterisk-Java to be a framework, 
>> though not so much with PasAGI which is more of an class object wrapper around 
>> AGI functions that I wrote a while back because I'm lazy that way ;)
> 
> Indeed and I think such a higher level API could be implemented in
> different languages. There is/was a port of the Asterisk-Java API to
> .Net at least. I think especially the "live" API of Asterisk-Java is
> worth having a look at. It provides an object view on top of AMI with
> rich objects like Channel and methods like hangup() and redirect().
> So it makes the developer focus on his tasks rather than thinking in
> terms of actions and responses.
> 
> Asterisk 1.6 includes a new feature that allows using AMI as a transport
> for AGI commands, there abstraction becomes even more important.
> For Asterisk-Java I am currently adding support for that in a way that
> allows the developer to run the same "AGI" code either through FastAGI
> or AMI without knowing about the underlying details.

Where is more information on this new feature for Asterisk 1.6?  Any details?

> 
> If someone is interested in defining a language-neutral general higher
> level API that can be implemented in a variety of languages I am happy
> to support this effort.


This would be refreshing as the current AMI output is a little all over the 
place.  Example:

Conf Num       Parties        Marked     Activity  Creation
111            0001	      0001       00:17:57  Dynamic

Above is a line from MeetMe command issued from AMI.  After the header line, 
each successive line denote information about a conference.  No problems there, 
except there is an extraneous Tab (#9) character right after the "Parties" field 
which screws you up when parsing until you figure out that there is a Tab 
character there.  There appears to be no reason to have a tab character there 
that I can see, well maybe to trip up unwary developers ;)

>> I'm not sure what your point is, but I'll say that I'm a definite proponent of 
>> abstraction layers provided they don't bar access to lower level logic when I 
>> need it.  I think you'll agree that good abstractions lend themselves to reuse 
>> and reduced development time (easy of use, less runtime logic errors, easier to 
>> extend, etc).
> 
> And don't miss the additional benefit of supporting multiple versions of
> Asterisk that you get almost for free. Asterisk-Java will run with
> Asterisk from 1.0 to 1.6 without changing your code even if the Asterisk
> guys decide to rename properties and the like.
> Just have a look at doc/manager_1_1.txt in the betas of Asterisk 1.6 and
> decide what your efforts would be to support Asterisk 1.4 and 1.6 if you
> stick to low level APIs.

Another great reason for abstraction/encapsulation IMO.

-- 
Warm Regards,

Lee

"Everything I needed to learn in life, I learned selling encyclopedias door to 
door."