> > 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.
>
> Right, and they shouldn't. If there is no compelling reason to
switch,
> why in the world should they? And why should we try to push them away
> from a stable platform?
Agreed - there is no reason at this time.
> > 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.
>
> That has nothing to do with Apache2 and has been available for Apache1
> for years. It just isn't a very popular feature. See the
apache_hooks
> code.
I know apache_hooks but after discussion with George and others, I
wouldn't feel comfortable recommending to clients, especially with
EXPERIMENTAL notes and no mention on php.net. The potential
functionality it could provide, however, would be very popular, on par
with mod_rewrite.
Whatever the particular feature is, my point is that the killer-solution
or feature will drive going on to new things.
Almost two years ago I ran PHP 4/Apache 2/threaded in production and it
ran fine. Of course, the only extensions I used were MySQL and Oracle.
However, I've since gone back to Apache 1, simply because there was no
compelling reason to live on the edge. A chicken-and-egg problem, but
perhaps it's time to think about incubating the egg.
H