Why we don't like PHP /

The Apache2 debate is more interesting. I am just running up a nice
new
AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find

and which does not bother me at all - ONLY Apache2 in the
distribution.
I KNOW all the reasons for feet dragging, and I am doing it myself
over
VCL/Win32 and Microsoft's latest 'standards', but at some point we
will
all have to give in an move on. Is now not the time at least to
start
treating Apache2 as a current version, and start looking into the
problems?

What problems? Threading will never be fixed in the large hundreds of
3rd-party library sense. So there is nothing to fix there. The only
question is whether we start recommending Apache2-prefork over
Apache1.
As far as I am concerned we start doing that when a majority of main
PHP
developers switch to Apache2-prefork. Personally I am completely

That presents somewhat of a chicken-and-egg problem. Production sites
won't be compelled to make a move until PHP recommends it in some way,
or if there is a killer feature that pulls people in, regardless of the
perceived stability.

unmotivated to make that change because I have a boatload of other
modules
written against the Apache1 API that I would need to port to Apache2
and
there just isn't a killer feature in Apache2 that warrants doing all
that
work for me at this point and Apache1 works fine. There isn't that
much
for a web server to do. We just need a simple working server.

If I am in the minority I don't mind suggesting people use Apache2,
but we
need a bunch of PHP developers to stand up and say they are using
Apache2-prefork in large production systems. It has never been a
matter
of not liking Apache2 or having some irrational bias against it, it is
purely a matter of what we use and what we know. If someone reports a
problem with PHP running under Apache1 we know how to fix that. For
other
servers, including Apache2, the pool of people familiar enough with it
to
provide decent support is much smaller. The documentation should
probably
be changed to better reflect that and make it sound less negative
towards
Apache2.

My personal view is that the bucket brigade API in Apache2 is
unneccesarily complex and quirky and we mostly have to defeat it
anyway
with PHP so it doesn't add anything for us. It just gets in the way.
There are a few exceptions to that, but not enough for me to be worth
the
complexity and the overhead.

I think this Apache 2 discussion underscores a change in the AMP
platform as a whole. We're seeing significant new versions of all
components - PHP 5, Apache 2, and MySQL 4.1 - and at the same time, a
move to commodity 64bit hardware platforms.

While "if it ain't broke, don't fix it" are words to live by, at some
point things should move forward. PHP has always been forward thinking,
and while Apache 2 might pose some technical challenges, it's in the
pipeline just as PHP 5 is.

Sure, PHP 4, MySQL 4.0, and Apache 1 will go down in history as a
powerful combination that changed the way much of the web develops and
operates. Changing from that is hard, especially when there's no real
compelling reason to do so.

Then perhaps some striking new functionality would push PHP 5/Apache 2.
While Apache 2 introduces new complexities, using some of the new
features could be advantageous, and a step towards the next generation.
For instance, allowing PHP to reach deeper into Apache, to a level
similar to that of mod_perl, could provide significant new features and
value. Getting PHP to control URL rewriting and logging, for example,
could be new features that drive demands from end-developers, and at the
same time generates interest and challenges for those developing PHP and
Apache themselves.

With other new developments like 64bit platforms, simply, "times, they
are a-changing." Does it make sense to change things just for the sake
of keeping up with version numbers? Of course not. But changing to
enable important new functionality might drive development on both ends.

Hans Zaunere
President, Founder
New York PHP
AMP Technology
http://www.nyphp.org