[VoiceOps] Any subscribers from the UK?

[Peter Beckman]

On Tue, 4 Aug 2009, Alex Balashov wrote a lot of things that Peter Beckman
cut, not because they are not worthwhile, but because his response is
significantly less verbose:

> I realize you don't disagree with me on most of this.  I just think that 
> these premises lead to the conclusion that there's no way something like PHP 
> can be the ticket, whereas you clearly don't.

  Honestly I agree with you on almost all points -- PHP isn't the best,
  greatest or most scalable solution to scripting Asterisk via AGI or
  FastAGI.  In my opinion PHP is a legitimate language that a FastAGI daemon
  can be written in and function, maybe even function well.  I think Bash
  would be a worse choice to write a FastAGI daemon in, but you could.  You
  might even be able to use a whole bunch of pipes (or socat) and some GNU
  tools to build one.

  PHP can and does work, and so does Perl, and so does C and C++.  I can
  write a FastAGI daemon in all of them.  I can likely build it with some
  extra work, a few extra tools, maybe a different method of compiling and
  actually make it scale well in all three languages.

  For customers who are not sophisticated, and who have limited budgets,
  they can hire limited programming resources who have less knowledge about
  the kinds of intricacies we have learned over the years.  This leads to
  the "exten => _X.,n,AGI(asterisk.php)" lines in the config that we see and
  immediately cringe at upon seeing.  We know that some languages are better
  at being long running processes than others, and when the programming
  resources are available, are able to choose the best one for the job.

  PHP is a choice, an option, one that I think is perfectly valid for some
  situations.  I've written a lot of cron jobs and command line scripts that
  work in PHP just fine.  Since there are resources on the servers to handle
  the bloat of using an interpreted language to run these scripts, there
  isn't any real problem with it.  There is a PHP CLI for this reason.

  Given the same resources, we'd probably both rule out PHP as the ideal
  solution for a FastAGI implementation.  It is, IMO, still a legit option.

> Good to know;  I had not considered the soft reload angle.  Thanks!

  No problem!  Just be sure that if your FastAGI is using HTTP API calls to
  your backend that you are able to manage DB changes gracefully.  Having an
  existing call make a call to an internal backend API that now requires an
  additional variable will fail unless that case is handled.  This is one of
  the reasons the FastAGI does not talk to the DB directly, but through HTTP
  API calls that are handled quickly by PHP.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------