PHP's great claim to fame has always been a solution to a domain specific problem, Delivering Web pages. It's relatively easy mixing of HTML and code (while at times very nasty), have proved quite a good solution for many people.
But as technolgy moves forward, I wonder if PHP will be required much longer. Why you may ask, since I've got craploads of PHP code lying around in my subversion folders. Well In addition to most of my new projects using ExtJS to deliver the interfaces, which has almost totally removed PHP from rendering tasks. The last few weeks I have been using Mysql's newish Stored procedures, which move the alot of application logic and rules into the database, and seriously reduce rather kludgy code in PHP. Not only that it also reduces the data going back and forth between PHP and Mysql.
So PHP is doing less and less of the work, to the point where if there was an apache module that did mysql stored procedure calls based on the request URL, and returned JSON, I suspect PHP would be practically obsolite.....
Anyway started playing with apache modules today... - not enough time to do anything substantial, but there are a few fixes needed to this page.
http://www.ibm.com/developerworks/linux/library/l-apache/The build lines should be something like this.
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
And the FOREACH loop in it should use
curr_bucket = APR_BRIGADE_FIRST(bb);
while (curr_bucket != APR_BRIGADE_SENTINEL(bb)) {
...
curr_bucket = APR_BUCKET_NEXT(curr_bucket);
}
Anyway I wonder if anyone has done a Mysql/Json apache module.
Comments
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'
