Smoking toooooo much PHP

gcc -fPIC  `apxs2 -q CFLAGS ` -I`apxs2 -q INCLUDEDIR` 
   -c time_cookie.c -o time_cookie.o

gcc -shared  -lapr-1 -laprutil-1 time_cookie.o -o time_cookie.so

curr_bucket = APR_BRIGADE_FIRST(bb);
while (curr_bucket != APR_BRIGADE_SENTINEL(bb)) {
    ...
   curr_bucket = APR_BUCKET_NEXT(curr_bucket);
}

Nah.
Nah, each has their preference, already in-house developers, companies (most of them) don't like to change (Probably the reason why there's still so many php4 users out there)

l-apache is fun for multiple people team. I have used quite a bit of it and it's still C... the reason of PHP's success :P

Other thing, about your mysql/json, I know it's not this, but a big hype at the moment seems to be that couchdb thingy, with it's json interface. Someone basically have to do the same thing for mysql. I'd probably try it, but I like what you can do (faster than doing it in java) in php.

But again, it's a matter of religion, Some tasks have been proved to be bad fro php and some others no.

Unlikely
For certain trivial applications, yes, you can go straight from a single datasource to javascript in the browser, but for anything substantial you are going to want to connect to many different backends and do a lot of data munging. Exactly what PHP is good at.

You definitely don't want to send more data across the wire to the client than is necessary, so doing the sorting, filtering and whatever other data munging is necessary on the server is always going to be a task for something like PHP.

prototype it in PHP
To be a little broader here, I'd say we're finally seeing a movement to have servers serve up data instead of data embedded into presentation. A lot of folks seem to have tried this SQL-over-HTTP thing over the years; brings up some interesting quandries. I'd suggest, if you're interested, to prototype this in PHP; if you find a story that works for you, you could then mod-ize it. I'm not sure that you'd actually get any better performance out of it than you would with PHP though. If I were betting, I'd bet you WON'T get any significant performance difference from it.

not so soon
A lot of folks have tried sql-over-http over the years,and it basically never caught on.

For myself, I have been a big fan of massively using stored procedures in databases long before mysql started thinking about subqueries: eg. in Oracle stored procedures
_ are faster to execute than multiple sql statements
_ allow to centralize business logic so that you can have many apps talking to the db without reimplementing the same rules every time
_ make easy manipulating datasets

otoh plsql syntax is old and crufty, hashes and regexps are a pain to use, and code maintainability duffers because of poor oop support

I'd say php has hit a sweet spot in between core business logic (stored procs) and the more mundane presentation logic (html, css, js, templates), and it will be hard to displace it. Let's call it "glue logic" layer...

Using stored procs you can do data filtering and sorting, so in fact there is no need to send more data than necessary to the client (in fact some 'classic' db apps built using traditional languages are far worse in that aspect. Try to tell to a stock table widget from Delphi or VC that it should only load a few items a time...).

The main problem I see right now is that before sending data to the client you usually end up having to send really huge js libs. And, while js support has really evolved, there are still many drawbacks:
- js cannot be sent gzipped like html is because of faulty clients
- antiviruses scanning any non-trivial js for malware will grind a cray to a halt
- js is executed on a single thread
- old machines do not haw enough horsepower to run modern browsers at decent speeds, and even less the big js libraries
- accessibility laws still mandates the site needs to work with js off
- etc...

ы
should have been titled 'smoking too much mj'

-
You could have a look at http://code.nytimes.com/projects/dbslayer

MySQL based CMS
My coworker Harrie Verveer once wrote a post about a CMS that was almost entirely MySQL based. He only used one line of PHP to call the MySQL stuff. You can find his post here:

http://www.ibuildings.nl/blog/archives/64-Build-a-website-using-MySQL-functions-instead-of-PHP.html

Although this is a nice experiment, I think it's not really a valid approach from an architectural point of view.

JSON in MySQL
in case you hadn't seen this yet, it might do some of what you want:

http://www.mysqludf.org/lib_mysqludf_json/