[VoiceOps] Any subscribers from the UK?
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. :)
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