Re: [asterisk-users] Higher level API on top of AMI and AGI (was Re: Real API for Perl?)
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 PartiesMarked Activity Creation 1110001 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
Re: [asterisk-users] Higher level API on top of AMI and AGI (was Re: Real API for Perl?)
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? I wrote this blog entry when I was writing the AsyncAGI feature: http://www.moythreads.com/wordpress/2007/12/24/asterisk-asynchronous-agi/ This is the bug entry: http://bugs.digium.com/view.php?id=11282 I changed my mind regarding the behavior of this feature after opening the bug entry, so the initial description of the bug can be confusing and totally different from the final implementation and behavior, so you will have to read all the comments in the bug entry to understand what is this about. Moisés Silva -- I do not agree with what you have to say, but I'll defend to the death your right to say it. Voltaire ___ -- 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
Re: [asterisk-users] Higher level API on top of AMI and AGI (was Re: Real API for Perl?)
Moises Silva wrote: 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? I wrote this blog entry when I was writing the AsyncAGI feature: http://www.moythreads.com/wordpress/2007/12/24/asterisk-asynchronous-agi/ This is the bug entry: http://bugs.digium.com/view.php?id=11282 I changed my mind regarding the behavior of this feature after opening the bug entry, so the initial description of the bug can be confusing and totally different from the final implementation and behavior, so you will have to read all the comments in the bug entry to understand what is this about. Moisés Silva Thanks. That's pretty slick. It could add some flexibility, but as you noted on your blog, you could just as easily redirect to a FastAGI server, etc. Being able to call AGI's on a channel through the AMI seems like it could have some possibilities as well. -- 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
[asterisk-users] Higher level API on top of AMI and AGI (was Re: Real API for Perl?)
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. I think this kind of abstraction is key to the success in Asterisk-enabling other applications. 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. 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. =Stefan -- reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] WWW: http://www.reucon.com Steuernummern 215/5140/1791 USt-IdNr. DE220701760 signature.asc Description: OpenPGP digital signature ___ -- 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
