Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Dec 2004 08:04:16 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F87073481D1@ehost011-1.exch011.intermedia.net>
Thread-Topic: [PHP-DEV] Why we don't like PHP / 
thread-index: AcTnGTcL/9iqDXBqR3KrbxmzlZePRwF2qg+Q
To: "Rasmus Lerdorf" <rasmus@php.net>,
	"Lester Caine" <lester@lsces.co.uk>
Cc: <internals@lists.php.net>
Subject: RE: [PHP-DEV] Why we don't like PHP / 
From: hans@nyphp.com ("Hans Zaunere")


> > 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?
>=20
> 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.
>=20
> 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.
>=20
> 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