VoicePHP by TringMe
TringMe, an Indian start-up just released its new VoicePHP service, which allows you to develop voice applications using PHP.
This is definitely cool stuff, though I see quite a few issues with implementation. HTTP, is, by design, a non-persistent transaction, and a phone call requires persistency while the call is in progress; therefore, there is no way for PHP alone, to handle "Voice" requests.
The only way to really make this work, is to have an external server (effectively a PBX of some kind) that handles the call traffic, that is simply polled (in some fashion) by PHP on a per request basis. Those requests could be polled via Ajax, or even a comet-like system, but it's still not handled directly via PHP. I assume this is where their VoicePHP "Server" comes in.
So, in this sense, it sounds simply like a PHP wrapper around the TringMe REST API, which is something that can already be done in other ways, like accessing the Asterisk Manager interface via PHP using asterisk-php-api, but with one interesting twist-
It looks like (according to their FAQ) you can access the audio streams directly from PHP- which is pretty interesting, depending on how they've implemented it. Given the (generally) short transaction lengths of an HTTP request, I'm not sure how you would realistically pull audio from a real-time source (like a phone call), or play-back an audio clip on to a call, unless you used some sort of scheduling system.
ie- use PHP to decode and audio file (say .wav or .mp3), and then send the file to the VoicePHP server, which schedules the audio clip for playback, and returned immediately. It's then played over the call in "real-time". PHP could then poll the VoicePHP server to get status about the playback.
I've signed up for a beta account to play around with it, hopefully I'll see something from them soon.
memcached (and facebook)
I'm really impressed that so many big companies, like facebook and google, have taken the time to release patches and source code, back out to the open-source community. Being able to improve memcached throughput from 50,000 requests/s to 200,000 requests/s is an amazing achievement.
The changes that the facebook guys have made to memcache are going to help a lot of people out there, including fonolo. We're using memcache heavily in-house, not only for web-based caching, but for a lot of the back-end VoIP and speech recognition applications.
We, obviously, don't require the throughput that facebook does- given they just recently released data that showed they were adding more than 600,000 new users per day, more than 70% of which are coming from outside the USA. That's growth at a staggering rate!
I have to say, that I'm a fan of facebook, and what they've managed to achieve, in a relatively short amount of time- I just have to wonder how long it will all last? Increasing your user-base by 600,000 users per-day; where is the plateau? Will it all eventually just topple over on itself?
Imagine when the next big social networking app comes out; will there be a mass-exodus from one to the other? or will facebook be so far in-grained in it's users, that they won't have any other choice but to stay?
No matter what happens, it's nice to know facebook is working out all the bugs for us.
Net::fonolo 1.3 Released
I justed released the latest and greatest version of Net::fonolo, a PERL module for accessing the fonolo.com developer program.
This release was pretty basic; just added support for the new API method company_list(), which returns a list of all the companies in the fonolo database, either by page, or by a date (so you can do incremental updates of a local cache).
If you're interested in signing up for the fonolo developer program, click here.
The Net::fonolo module is available on CPAN , or here:
Added: Dec 17th, 2008
Net::fonolo is a PERL module for accessing the fonolo developer community.
Worst Browser Ever
Even Microsoft doesn't want you to use Internet Explorer;
There was a pretty severe bug found, that apparently affects all versions on IE (even the yet-to-be-released IE8 was affected)- what's even more surprising to me, is that so many people are still using IE6. I guess it's simply because it came with XP, and because of the enormous flop of Vista, there's probably even more people using XP than pre-vista-gate.
I've been using Chrome as my primary browser ever since (almost) it came out; it has quite a few bugs in it, and the bookmarks support is terrible, but it's fast and light- and doesn't seem to eat memory like Firefox likes to (for no apparent reason.)
... if only the google guys would get on a plug-ins system of some kind- I hate having to switch back to firefox all the time for firebug.
But seriously- IE6? with all the CSS and Javascript "issues"? and not being able to render transparent gradients properly?
Maybe this exploit and all the press it's getting is really a blessing is disguise for all us developers out there; maybe this will force a large percentage of the IE6 users over to the "other" pile.