bravo! ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 11:05 PM Subject: Re: consider reopening 1.3
> > Geez... it's nice to discover everybody hasn't just dropped dead! > > I see a lot of healthy 'things to do' coming out of this > thread that could inject a lot of life back into the > development... which is what the various threads the past > few days have all been about. > > Action items?... > > Facts to face?... > > ------ > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. > ------ > > This gives someone who might be stuck with one of those pre-fork > only platforms, or anyone who just WANTS to stick with pre-fork, > absolutely NO INCENTIVE to upgrade at all ( ever! ). > > The whole module-rewrite thing is another issue but as long as > the same process model is SLOWER in the 'new' version than the > 'old' version you have a serious migration roadblock that > isn't going to go away. > > Okay... problem identified... what to do? > > - Verify that's it's true. ( seems to be ). You have to > KNOW, yourselves, where you are on the stopwatch and not > wait for usrs to tell you. > - If it's not (true)... do some marketing and make sure people KNOW IT. > - If it is... fix it. Make it NOT TRUE. > > I popped off and looked at 2.0 code again just now and I can tell > you right now it's (still) the filtering that's killing it. > > The core filters are going to need to be totally optimized > and kick-ass if there's any chance of 2.0 matching 1.3 speed... > and that's before anybody loads any 'extra' (optional) > filters ( other than core ). > > I don't think this is something any one person can do considering > no one seems to really have the 'whole picture' of the filtering > at this point and the orignal (primary) author is gone. > > I have a few suggestions but I'm not even sure I have > the 'whole picture' on how to improve things. > > One idea, of course, is to code in some BYPASSES ( on a config > switch? Dunno ) that would allow 2.0 pre-fork core filters to not > actually use the filtering (scheme) at all and put it right back > into 1.3 performance range. > > I am by no means suggesting you bring back BUFF for the core > filters... but I AM suggesting there might be ways to > BYPASS all the BUCKET_BRIGADE stuff at the core level, if > that's the way someone wants to run it. > > The moment someone starts loading a lot of 'optional' modules > you'd probably have to re-engage the filtering but I'll bet > you a dollar to a donut there are a LOT of people running Apache > with nothing but out-of-the-box options and CORE filters only. > > You might even be suprised how MANY people just run it that way. > > I think you would see a MAJOR bump in 2.0 usage numbers > if there was any way 2.0 pre-fork could be FASTER than 1.3 > in a same-box same-environment scenario. > > You can't really fix the module-migration roadblock nearly > as easily as you could FIX THIS. > > ----- > FACT?: There are still some non-maintenance mode things that > people have already expressed they would like to see added > to 1.3.x and probably more 'ideas' lurking nearby. > ----- > > I say... let it happen. > > Whether it was 'officially' closed or not... when someone > can't get a 2 line logging patch added to 1.3 after 6 > months of trying then that is CLOSURE no matter how you > look at it. Make it not so. > > Just let it be known that 'worthy' additions to 1.3 > are still WELCOME and maybe some fresh air will blow > in the window. > > ----- > FACT?: One of the biggest roadblocks to 2.0 migration is > ( and will remain ) module migration. > ----- > > No one even knows how many freakin' 'in-house' modules there > are out there ( security, auditing, billing, etc. ) that people > depend on for their 'business' needs but you can be sure those > 'in-house' modules are what bring home their bacon and are > MORE important to them than Apache itself. > > In a lot of cases these people are using (private) modules > written FOR them by someone who is long... long gone and > they really don't have the faintest idea how to get it > 'migrated' to some 'new version'. > > It's too late to talk about total forward-backward compatibility > for 1.3 and 2.0 modules ( that opportunity was already blown > at the design stage ) but it IS POSSIBLE to start a discussion > about providing better 'compatibility' between modules. > > Example: If a simple Apache 1.3 module is already NOT using > APR but simply relies on the old BUFF API wrappers... it's > perfectly possible to just 'load' that module and run it > under Apache 2.0. No kidding. > > All you have to do is have some way for 2.0 to 'fake' the > old BUFF calls with a 'filter wrapper' around that > (simple) module. You might even be able to do it by > 'ifdef'ing the old BUFF calls with new MACRO calls > but that would require a re-compile. > > This would require some ( a lot? ) of code in the core > module loader/runner that isn't there right now but > IT COULD BE DONE. > > If Microsoft can carry their DLLs forward through 3 > major architecture changes... you can do the same. > > It just takes adding the right 'smarts' to the Server itself. > > ---- > FACT?: Whatever the target codebase... it's become nearly > impossible to get patches reviewed. > ---- > > This is obviously going to be addressed and will > probably be the MAJOR discussion topic in Las Vegas. > > Hooray! > > Whatever can be done to RENEW interest in Apache > development ( see all of above ) and just generally > crank the forum volume back up will probably help. > > Yours... > Kevin Kiley > > PS: FWIW... > > > [EMAIL PROTECTED] wrote... > >> > >> > and mod_* support ... last I checked, mod_gzip is still Apache1-only, > >> > >> mod_gzip? Try mod_deflate, it is included with apache 2: > >> http://httpd.apache.org/docs-2.0/mod/mod_deflate.html > > > > Didn't know about this ... will look at it, thanks ... > > mod_gzip was actually written FIRST for Apache 2.0 sometime > in the distant past when there was a ( false ) rumor > that 2.0 might actually be nearing a release. It > worked fine against the brand-new 2.0 filtering APIs and might > have been the first module written to use them, even before > mod_include was re-worked. > > When the rumor turned out to be false and that it might be more > than a YEAR before 2.0 got anywhere near a release... I simply > BACK-PORTED it to Apache 1.3 because I didn't want to wait > that long for people to start using it. > > So mod_gzip has ALWAYS been available for 2.0... even long > before 2.0 was finished. Porting it BACK to 1.3 was an after-thought. > > mod_gzip is officially maintained ( by many others now, > and NOT ME ) at SOURCEFORGE... > > http://sourceforge.net/projects/mod-gzip/ > > ( That's a DASH in mod-gzip part of the URI and not an UNDERSCORE ) > > or somebody ( don't know who ) also added it to FRESHMEAT... > > http://freshmeat.net/projects/mod_gzip/ > > ( Now it really is an UNDERSCORE in 'mod_gzip' part of URI ) > > The 2.0 version(s) of mod_gzip are also found at... > > http://www.gknw.com/development/apache/httpd-2.0/unix/modules/ > > Just grab mod_gzip-2.0.40.tar.gz > > ...and right here in Apache's own code archives. > > Complete working version(s) of mod_gzip for Apache 2.0 were > donated to ASF a long time ago. > > I will be the first to tell you that there is functionally > no difference between mod_gzip and mod_deflate. The only > difference you will find is that mod_gzip still has many > more options for 'including' or 'excluding' things from > being compressed in order to deal with the 'realities' > of modern and legacy User-Agents. > > > > > > > > > > > > > >
