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." _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users