> > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
