[VoiceOps] Any subscribers from the UK?

[Alex Balashov]

Peter Beckman wrote:

>  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).

I suppose that if the rationale were so intricately bound up in the 
benign and understandable motive of code re-use, that is logical and 
forgivable.  No argument there, given that premise.

There are various observations one might make about PHP runtime 
performance that suggest that it really doesn't work well at all outside 
of mod_php and should not ever be used in standalone processes, but I'll 
stay away from that because that really does have the tendency to 
degenerate into a religious debate, and your point is fundamentally 
sound and cogent.

>  First off, calling AGI(somescript.php) is awful.  

It is, but most of the broken implementations I am brought in to fix do 
exactly ... that!  :-)

>  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.

That sounds very workable.  I suppose there might be something to be 
said in favour of non-blocking I/O / synchronous I/O multiplexing in a 
unitary process versus forking a new process or thread for every call, 
but that only becomes a concern with very, very large amounts of call 
setups.  The mere fact that you have a FastAGI server versus invoking 
local AGI puts you like 1000% ahead of people who don't.

I've built many FastAGI services - whether for call routing or more 
esoteric business logic - in Perl as well.

>  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.

There is a considerable body of evidence suggesting that although PHP 
does expose a socket API, using it to do sockets is a terrible idea 
because it just doesn't perform well at all.  I don't know why anyone 
would write a server - FastAGI or otherwise - in PHP.

Besides, PHP does not really have the appropriate low-level dimension 
for heavyweight or nuanced system calls;  that's not what it was 
designed for.  Then again, I suppose people make that argument for Java, 
too.

On the other hand, I have no trouble believing it still works better 
than local AGI() script invocations.

>  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.

True, very true.

>  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.

Maybe.  I suppose it's just hard for me to see, as someone with a 
programming background that almost entirely consists of socket-layer 
programming and network protocol implementation (in C), how PHP - given 
its architecture - can do those things in a scalable fashion even if it 
does bother to publish APIs for the underlying system calls.  Managing 
large amounts of I/O-bound processing just isn't what it was built for 
at all.  Even my curl_*() calls out of PHP are dog-slow.

It's a qualitative issue -- "just because you can, doesn't mean you 
should."

The real answer lies in robust performance studies and in the details of 
PHP's runtime implementation.  I have neither of these annals at my 
ready disposal in order to illustrate that point.  There's just a 
general principle that high-level, non-typed web languages aren't 
designed to participate in the same problem domain as general-purpose 
programming languages and/or languages on which systems are built at 
that lower level of abstraction.

It is within the realm of conception that you could write a virtual 
machine container/hypervisor in PHP, if only the interpreter exposed the 
system calls and other primitives you'd need to pull it off.  But it's 
not done for a reason--surely you can agree. (Except perhaps for the 
novelty/Slashdot factor by someone with far too much time on their hands.)

>  For my Perl FastAGI, I use Net::Server::Fork and Asterisk::AGI (with a few
>  fixes and modifications) and it works great.

Interesting.  I've tended to use Asterisk::FastAGI in the past, but it 
never seems to obey my bind port parameter on the initial invocation.

-- Alex

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775