My Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from coogle. Make your own badge here.

Quicksearch

Alan has smoked too much PHP

Thursday, November 15. 2007

Alan, I think you were smoking way too much PHP when you wrote this post.. This in particular really surprised me to hear you say:


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


While I do understand the concept your explaining, I simply can't see how the model is practical at all for two big reasons:

Reason 1: Businesses will never build applications designed to make money when the entire application is transmitted open-source to any client which requests it.

Reason 2: Without a server-side language such as PHP, there is not a viable security model. Javascript data validation is a half-measure at best, and do you honestly believe that it makes sense to use stored procedures written in SQL to scrub data?

While I think Alan really did go a bit off the deep end, he has touched on a pretty interesting point though. While I can't see the server-side ever going away I do think that in the near future the development model will change from what it is today to a completely event-based model based on a json-powered message bus between the client and server. IBM's QEDWiki uses Zend Framework to create such a bus and I have to say it's a very impressive architecture. The idea that PHP programming will for a lot of people resemble Visual Basic is really a lot closer then a lot of people might think.


Trackbacks

John Coggeshall's Blog: Alan has smoked too much PHP
In a new post to his blog today, John Coggeshall comments ...
Weblog: PHPDeveloper.org
Tracked: Nov 16, 10:58

Comments
Display comments as (Linear | Threaded)

While it's not going to solve all those issues. - The idea comes out of the fact that 90% of the PHP code I've been doing recently, effectively just pulls data from the database and renders it as JSON, or just does quite simple INSERT/UPDATE/DELETE etc. - which is a complete waste of PHP code in most cases....

- Login/ cookie models can be made to work. without the PHP overhead - not a killer issue. - so no opening your application to the world would not be a huge problem to solve.
- What validation do you need for fetching data. / and for sending data, A large majority of applications do not need significant data validation. And doing that at the data storage layer (eg. stored procedures) has other huge benefits in the long run anyway.. - Protecting the data integraty by providing safe access for any type of application - not only PHP.

The more I looked at it, apache was not the right solutions (apache hooks are still a bit of a nightmare to write).
A simple threaded server possibly in D connecting Mysql and outputing JSON looks far simpler to write an maintain.

(delete the last one - too many typos..)
#1 Alan Knowles (Homepage) on 2007-11-15 20:41
"Reason 1: Businesses will never build applications designed to make money when the entire application is transmitted open-source to any client which requests it."

Mhh. Gmail? - that's pretty much entirely Client side... - and makes money (businesses pay for it.)
#2 Alan Knowles (Homepage) on 2007-11-15 22:47
Well it's hard for me to argue what's client side and what isn't, but I am pretty confident that there is a significant amount of code on the server side in Gmail. There is obviously huge amounts of UI code on the client, but again we all recall the security breaches that Gmail fell victim to which I am sure had a server-side solution which was not handled in the data layer.

Again, my point isn't that your complete thought is wrong -- where you think PHP is becoming obsolete I believe it's role is simply changing.. Much in the same way 7 years ago people thought it was a good idea to embedded PHP and HTML together and now feel that separating business and presentation logic is a better approach, I feel that there is a similar trend to separate UI logic from business logic through AJAX -- but that doesn't eliminate the server side..

Also, what are businesses paying for there? It isn't the snappy interface alone -- in fact there are a few really slick snappy OSS webmail clients out there that do that.. its the search, storage capacities among others that I think really are the value-add here.. (I really don't want to argue about Google's business model though, anyway)
#2.1 John Coggeshall (Homepage) on 2007-11-16 15:01

The author does not allow comments to this entry

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/include/plugin_api.inc.php on line 562

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spamblock/serendipity_event_spamblock.php on line 451

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spamblock/serendipity_event_spamblock.php on line 476

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spamblock/serendipity_event_spamblock.php on line 520

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spamblock/serendipity_event_spamblock.php on line 819

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spartacus/serendipity_event_spartacus.php on line 316

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h04/mnt/28311/domains/blog.coggeshall.org/html/plugins/serendipity_event_spartacus/serendipity_event_spartacus.php on line 360