PHP: Present and future, Rants and raves
----------

I decided to just post this article now, as it's been sitting around for a bit.. 
I'd rather get it out there (incomplete) than just sit forever..

This article is more like a personal opinion, comments and feedback on PHP. 
It's what I like, don't like and would like to see in future versions. Also what's 
wrong with PHP. Now before Rasmus comes over with a pipe and beats the 
crap out of me you have to at least hear me out.

Firstly what's good about PHP. It's fast, easy to write and with just a small
team of devlopers you can turn a concept into a fully breathing online 
application in no time.

PHP has far surpassed what even Rasmus (the creator) himself could have 
hoped for such an application. In the past short period of time it has grown 
in leaps an bounds in features and speed. Reliability has always been there 
as it is typically backed up by the rock solid apache webserver.

Now here comes the problem. PHP is almost too easy. Not that that's a bad 
thing.. But what you end up with is alot of beginner and intermediate 
programmers working on what could be classified as an enterprise application. 
In the end you end up with something that from the web users point of view 
works fine. But from a programming point of view is just a disaster. It happens 
a lot, even here on PHP4 bulletin board.. someone having a very simple 
problem they can't understand, something so simple it's scary, but they've 
copied code from somewhere else that connects to databases and does lots 
of magical things.. now that's scary! And some of these people are writing and 
working on large scale internet sites that perhaps generate money, provide 
jobs, etc. It's typically nice to know that you company/website is run by 
someone who really knows what they are doing..

PHP has a certain amount of object oriented capability, and I believe that it 
needs to be exploited more. If your a developer and are not writing using PHP 
objects, then you are still a junior/intermediate programmer in my books. 
Being senior means you do things typically the right way and can back up why 
they are the correct way. OO PHP isn't that hard to get into and the paybacks 
are pretty nice.. Clean, scalable and re-usable code, that can even be 
understood by beginner programmers, creating an environment kinda like what 
Java tries to do.. Use java beans to store logic and JSP to present it.. 
Similar with PHP...

Separate logic and presentation, senior programmers write objects.. Juniors learn 
how to load up objects and call methods to extract data for frontend operations.. 
They need not know how the object magically can pull this information on request.. 
only that it will. A junior developer with basic skills and an object/class API can 
frontend pages come to life very quickly.

Enterprise's have for a long time been subbing PHP as not ready for the enterprise 
application development.. In some ways they are correct, in some not.

What PHP needs: (basically my wishlist)

PHP needs to be expanded into a full blown container, such as java servlet 
containers. This allows for contant runtime data to be store in session memory, 
something PHP lacks. Now I've played with the Zend optimizer (I think that product) 
a bit.. And it's got a neat feature where you can goto a specific URL and view 
information about the webserver cache and what Zend is doing for you.. That's 
part way to where PHP needs to go.. There is basic SHM memory capabilties with 
PHP now.. I haven't looked at it much yet..

PHP session management is done thru either disk based file storage or database 
storage. Having the ability to store client information in memory based session 
container is very attractive to high volume sites. It eliminates the constant 
connections/queries from webservers to backend databases.

Up to this point, most people refer to a PHP application as a bunch of related 
script, dumped into a directory that work together to perform some task. Typically 
an application is nothing more than an apache virtualhost pointing to a directory 
where all the project files are dumped.. PHP needs to push past that image.

Now once you've got PHP to this point, (a runtime container) PHP can itself be 
managed. Ideally PHP would fire up and listen on a management port with a 
pre-configured administrator password. The PHP RAI (Remote administration 
interface) you could connect to this port via some utility and get information 
about the server, such as running applications, memory usage, and do application 
deployments, etc.

This directly leads itself into the next item, PHP application archive format. For 
those out there who write in java as well, most know about WAR and EAR files. 
They are "Web application archive" and "Enterprise archive".

In all reality they are just jar'd (pkzip'd) files with a special extension and a 
specific structure. Inside there is a XML configuration file that explains to the 
server what all the files inside are and how to handle them. These type of files 
are critial to enterprise applications as they speed up the automatic deployment 
process to large server farms.

If PHP had something like this you could package up all your code, graphics, 
special config file, transmit it to the PHP RAI and it would automatically 
uncompress the file and deploy it on the server. Best of all this could be done 
remotely without even needing to login to the server other than having the 
RAI login/password.

These new PHP applications could have custom PHP.ini configuration files for 
each of them that the application server would respect and allow for many 
distinctly different applications to be deployed on the same servers
without having to install multiple apache's or mess with changing runtime 
configuration variables for each application.

This would be very ideal for large web clusters in load balanced environments 
that have 20 servers running the same application or same multiple applications.

That capability leads itself into the last section.. Once a deployment format 
has been decided, people can move from using vi, pico, notepad, etc. to edit 
and manage their files, to using some of the advanced apache build applications 
such as ANT. A developer could make changes to PHP source files, tell ANT to 
build and deploy the changes on the development server and it would do just 
that. Perhaps compile first, then package them and transmit them to the RAI 
where they would be hot-deployed and ready to be tested. Then when it's time 
to update the production servers, the developer or someone else just tell ANT 
to deploy on production servers (could be a long list of them) and it will package 
things up, and deploy the PHP application to all of the servers, where they
would be seamlessly hot-deployed without any work at all.

There's alot of potential for growth with PHP.. Hopefully Rasmus and Zeev and 
all the other great PHP developers will have already had some of these ideas 
and be implementing some of them into PHP5 which is already in development.

Links
-----
ANT: http://ant.apache.org/