On Sat, 1 Aug 2009, Alex Balashov wrote:
I don't mean to sound derogatory, but what is this enormous fixation that people have with building AGI scripts in PHP-AGI?
PHP is a language designed for serving dynamic web pages; of all the runtime environments suitable for the development of standalone utilities, it is absolutely the worst and most perverse one you could use.
You have some very valid points, and some ones I disagree with. Here's why we do it, and how we do it better. Before I start, I strongly disagree that PHP is bad for handling Asterisk dialplan logic. You want to write your business logic in code once, then reuse it. We happen to expose our business logic via a PHP API that our Perl FastAGI uses, but not everyone has the talent/ability/forethought to build it that way. The easiest way to reuse that business logic code you wrote for the website is to build libraries you can reuse elsewhere. In this case, a PHP that talks to Asterisk in an AGI sort of way (not directly). First off, calling AGI(somescript.php) is awful. We decided to do it in Perl, but we could have done it in PHP. We implemented it as a FastAGI script, running as a TCP service that asterisk connects to on a listening local port. It handles all of our database connections, forks new processes off for each call, and does everything we need the way we want it done, not having to add on a bunch of hacked-together scripts and modules in Asterisk. Second, if you know PHP and nothing else, it is definitely easy to get it done in PHP, especially if your business logic is in neat libraries you can include and make calls to. If you call it directly via AGI(), it can and likely will hurt or kill your resources, but using it as a long running FastAGI daemon it can be managed and connections to the DB can be shared. Last, if all of your business logic is already done in PHP for your website, it's really easy to simply re-use this existing code in your AGI. And if you do it right and well, it may even scale fairly well. Your point however is still very valid: most customers do NOT do it right and well, and they should be motivated to learn how to do it better. I do think your downplay of PHP as an AGI language is simply misdirected. PHP can do FastAGI, and you can pool connections, fork processes, do things elegantly, same as with a Perl or C++ compiled FastAGI script. Of course we all know C++ will run faster, but we also know good C++ folk are hard to find, and once they build it, it's hard to find them again to update it. PHP programmers are easier to find, and if we simply educate them about how to build a FastAGI written in PHP reusing business logic already build into their website, well, it seems like a pretty good path to me. Are there better ways to do it? I'm certain. But most buseinsses don't have access to really and truly talented Asterisk admins who also know SQL and really can manage the full dialplan on a regular basis, who also know PHP well and can work on the web side of things too, and that's why they use PHP. Now go teach them to use a FastAGI written in PHP (it's not that hard) and they'll be a long way along. For my Perl FastAGI, I use Net::Server::Fork and Asterisk::AGI (with a few fixes and modifications) and it works great. Beckman References: http://www.packtpub.com/article/asterisk-gateway-interface-scripting-with-ph... (Nir!) http://us2.php.net/manual/en/function.socket-listen.php http://phpagi.sourceforge.net/ (not maintained) http://gattolino.blogspot.com/2009/03/asterisk-fastagi-server-in-php.html (incomplete) --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------