Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: zlib inclusion and mod_gz(ip) recap
From: Ian Holsman <IanH@cnet.com>
To: dev@httpd.apache.org
In-Reply-To: <11.1a5309ce.28caffac@aol.com>
References: <11.1a5309ce.28caffac@aol.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 07 Sep 2001 22:32:17 -0700
Message-Id: <999927137.24824.13.camel@c1619481-a.almda1.sfba.home.com>
Mime-Version: 1.0


looking back at justin's original request.
the code was posted ~1 month ago.
he reviewed it, he thought it was OK.
and asked.. 
'guys.. should we have this module included?'

a simple enough question.

it then degenerated into a flame war. 

It is hard to read you long and flamebait ridden comments
Kevin,  alot of people stop reading after the third 'asshole'
reference. I seem to remember you mentioned that ZLib wasn't 
the best candidate for realtime compression.

This whole flame war has left me with a bad taste in my mouth 
and I don't think GZ is going anywhere for the time-being. so 
I have gone back to working on other things 

My point to Jim J was really a question as to why. I submit code
regularly to the codebase, and commit patches. I do not see the module
I personally wrote as being any different. I do not claim to understand
how apache works, never did. 

I really am sick of responding to you Kevin, because all you will
do is ridicule me and other posters.

If you have anything constructive to say, then please do. Otherwise
shut the fuck up and let everyone get on with it.
 

On Fri, 2001-09-07 at 21:59, TOKILEY@aol.com wrote:
> 
> > > Ken Coar wrote...
> > > Current consensus appears to be to add it to modules/experimental.
> >  
> >  Ryan Bloom responded...
> >
> >  I don't see how that could possibly be the consensus, since I have -1 in
> >  the STATUS file.
> 
> The 'consensus' that Ken thinks he sees just diminished.
> 
> I am (obviously) not a committer but on the hopes that my opinion
> might actually mean something... I am changing my 'vote' on +1
> to adding mod_gz following the broil fest to a -1 so now there are
> at least 2 definite 'Not at this time' votes.
> 
> Here is why...
> 
> Regardless of the fact that I might be the author of any publicly
> available software that provides some similar functionality something 
> is just plain screwy about the way this mod_gz thing is being (seemingly)
> bombed into the core.
> 
> If I knew nothing about compression and/or Apache modules and/or
> the current state of 2.0 I would still have to say something is weird
> here and doesn't seem to following the usual *careful* path for
> putting anything into an Apache core distribution.
> 
> Here are just a few of the things that ( IMHO ) are a little 'weird'
> with regards to this all suddenly being a house on fire...
> 
> 1. The very self-described 'newbie' (Justin) who came out of nowhere 
> and basically said 'Hey fellas... I haven't load tested this mod_gz thing 
> but it worked with my Netscape browser ( only one tested? ) once or
> twice so let's bomb Ian's mod_gz into the core right now' now says 
> he is going AWAY for 2 weeks.
> 
> The very guy who wanted it there IMMEDIATELY is now disappearing
> for 2 weeks? That's odd.
> 
> Granted... Ian has done some more testing since Justin's request 
> ( I think? ) and posted 1 page of results ( Nothing following that ) but 
> at the time the request for core insertion was made there was no evidence 
> of any testing at all except the most basic of scenarios ( Ask for an
> HTML page and watch it appear in a browser ).
> 
> 2. I asked Justin myself where the 'fire' was and what prompted
> him to request the core-bomb-in and although he gave a fair 
> answer as to 'it ought to be there' ( which I cannot disagree with )
> he didn't really establish much of a basis for actual Apache CORE 
> insertion AT THIS MOMENT IN TIME.
> 
> If ( as he said ) he has seen 'weird things' while testing mod_include
> and mod_gz and ( as he said ) feels there needs to be 'another filter
> involved' for good testing... then the insertion of Ian's demo into the core
> AT THIS MOMENT is not a pre-requisite to debugging something. 
> Ian's code has been posted and it's there. If anyone needs to use it in 
> their 2.0 testing well... then just go ahead and DO it. 
> 
> That process ( just using it right away as-is ) would help find these
> filtering problems Justin seemed to be talking about AND I suppose
> it would help debug mod_gz itself BEFORE it becomes permanently
> part of anything.
> 
> I still don't see why the actual insertion of a not-very-well-tested 
> filtering demo into the core and the legal/official process that generates 
> is somehow a pre-requisite to finding filtering 'problems' in pre-BETA 2.0.
> 
> 3. Ian doesn't even understand why Jim J. would ask for a signed
> module submission form. No offense to Ian but this doesn't indicate
> that he himself understands the official module submission process
> and the legalities that surround it. Certainly not a showstopper but
> just part of the 'weirdness'. We got blasted all weekend for 'not 
> knowing how Apache works'... No one needs to blast Ian but he
> certainly needs to understand better why he must give signed 
> consent for his work.
> 
> 4. It seems no one has even proof-read the actual mod_gz code much.
> For starters... there are places where it's going to bomb simply because 
> it's using integers instead of longs. It won't show up until something
> is over 65k. It also doesn't really have the right ZLIB copyright information
> in it which would normally be the 'correct' thing for Apache to do with
> any public-domain dependent code dropped into the core.
> 
> 5. Dr Mark Adler ( co-author of ZLIB itself with Jean ) is currently on
> our payroll. He and I are currently discussing a few of the issues that
> were raised during the broil-fest about the actual suitability of ZLIB
> for your purposes. Somewhere in the discussions we tried to calmly
> point out what the concerns can/should be but all that got lost in
> the noise, methinks. It still should concern any Apache what the
> actual implications are of including a module in the core distribution
> that tries to use ZLIB as a real-time data compression engine.
> 
> The more I think about it... ZLIB is probably the way for you
> guys to go even though mod_gzip doesn't use it because using
> ZLIB would simply be easier for you guys in the long run. 
> Someone raised the 'trust' issue. Well... if you trust ZLIB
> then you should probably use it in lieu of anything else.
> You guys are not in the compression business.
> 
> Ryan Bloom himself said in about the third message following
> Justin's '"Let's drop this mod_gz puppy in the core" message that
> perhaps waiting until we hear from some people who are 'not on
> the list' was a good idea. Neither myself nor Peter had even joined
> the discussion at that point and Ryan's instincts were correct.
> 
> Maybe you should wait just a little longer to 'hear' from Mark ( Adler )
> himself at this point. If you don't trust what I know about ZLIB then
> I think you should trust what HE (Mark) has to say.
> 
> Ok... enuff said...
> 
> I am sure someone is going to come back with 'Methinks he doth
> protest too much' and/or some are going to do the usual 'iterate the 
> points' and comment back but it's really not necessary. All I was doing 
> is iterating MY reasons why I have changed MY earlier +1 to a -1.
> 
> People are free to stick with whatever negative or positive integer
> they want... mine has gone to -1 on this, at least for the moment.
> 
> Hard as it might seem for some of you who have a fixed-in-stone
> opinion about RC and/or me personally to believe... I still
> think this is a pretty good HTTP Server and my instincts still
> require me to speak up when I believe I see a mistake being made.
> 
> It isn't going to hurt anything to wait a little while ( perhaps even
> simply until the original advocate of the insertion gets back from the
> 2 week trip? ) and then just pick it up again. Maybe mod_gz will
> be even better ( and more well tested ) by then.
> 
> That's all.
> Take it FWIW.
> Thanks for your time.
> 
> Kevin Kiley
> 
> 
> 
-- 
Ian Holsman
Performance Measurement & Analysis
CNET Networks    -    415 364-8608