[VoiceOps] Any subscribers from the UK?

Alex Balashov abalashov at evaristesys.com
Wed Aug 5 03:25:05 EDT 2009

Peter Beckman wrote:

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

Well, I suppose if it comes down to a semantic question - that is, 
whether PHP belongs to a certain club of things which might be deemed 
"legit" for this purpose - it's difficult for me to persuasively ascribe 
any meaningful poverty to it as an implementational choice.  I don't 
know that anything can be ruled out as certifiably "non-legit," and 
certainly, if it's a resource consumption and processing overhead 
question, there is no shortage of similar scepticism with which Perl and 
Java (especially) could be viewed.  Obviously, back when we were 
twiddling bits to save memory in C, running a monstrosity like the JVM 
was out of question, yet today many things telecom are powered by it, 
and indeed, the computational resources are there.

I think the fundamentals are agreed upon, and to the extent that the 
matter of PHP is open, it mostly comes down to a sort of intangible 
software engineering heuristic that - although it holds great weight - 
is difficult to justify in purely functional terms, at least for 
anything less than very large values of n.  :-)

I abdicate the question with a parting thought:  Why is it that more 
high-capacity, commercial-grade stuff (of the standalone, not web 
front-end variety) isn't written in PHP?  Why doesn't someone like 
Metaswitch or Broadsoft implement internals in PHP?  To some extent, the 
answer is accounted for by the stubbornness of large-corporate fashions 
and entrenched interests surrounding certain technology stacks, as we 
well know, but I don't think that's the whole explanation.  It's not 
like these guys didn't get the memo on PHP or something.

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

That's a smart setup.  And, PHP is a fine language to use for an HTTP 
and/or RESTful API dispatcher.   :)

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

More information about the VoiceOps mailing list