In a message dated 01-09-15 15:16:16 EDT, Cliff Wooley wrote...

> On Sat, 15 Sep 2001 [EMAIL PROTECTED] wrote:
>  
>  > We decided not to wait any longer for a new BETA.
>  >
>  > Attached is the current source code for mod_gzip
>  > for Apache 2.x series. It has been tested
>  > pretty heavily and seems to be working fine.
>  >
>  > There is only 1 file... mod_gzip.c.
>  >
>  > You are free to do whatever you like with this
>  > submission.
>  
>  Cliff Wooley wrote...
>
>  Thanks Kevin.
>  
>  I took the liberty of applying a good dose of Apache stylistic rules
>  (might have still missed some things, but I tried).  

In the heated exchange last week that was one of my specific
questions ( major formatting concerns ) and the specific answer was
that it didn't matter much at this point in time.

If I had thought anyone still cared about where braces are I
would have done that myself.

> I also removed some
> more debug stuff (the r->notes things) since none of it ever seemed to be
> really used.  

Bad move.

Did you even read the code before you started butchering it or
bother to visit the mod_gzip website and look at all the existing
( and tested ) Apache log analyzers for mod_gzip?

The ability to add compression statistics to the Apache logs
via the r->notes interface was one of the things that people 
needed the MOST. 

If you have removed the r->notes interface you have just
taken a huge step backwards and made the code useless
for a lot of other people's hard work writing log analysis scripts.

> I removed the ZLIB license since I don't think any of this
>  code actually came from ZLIB.  

Cliff... now I really am confused.
I really don't know what you are talking about.

If a program USES ZLIB then it is SUPPOSED to have the
ZLIB license. For people that get so bent out of shape about
your own public license I would think you would have more
respect for other's licenses.

Take deep breath, look at the code, and I suggest you put
the COMPLETE LIBPNG/ZLIB license back. I believe when
the rubber meets the road your own Board Members will
require it to be there.

> The fact that it uses zutil.h is immaterial AFAIK.  

If you determine the right OS_CODE for the ZLIB/GZIP LZ77
header then you don't need zutil.h.

However... just look at the code in ZUTIL.H and you will see
you are better off trusting that header. It's been tested for
over 8 years and it does the RIGHT thing.

> If I'm wrong, somebody tell me and I'll put the ZLIB license back
>  in.  

See above. It really should be there if you are going to be using ZLIB.

> I also removed some of the verbose comments... 
> I think it's easier to read with fewer comments in some places.  

Geezus... ok... whatever.
You guys kill me.

Some of those comments were IMPORTANT because Apache 2.0 itself
isn't even finished yet and there was good information about what to
expect might need to happen when it is.

> I took out the version numbering
> since it'd be hard to keep that in-sync if this were in the actual
> httpd-2.0 tree.  It makes sense for a 3rd party module, but not for an
> official module.  

Sure... Whatever.
I still think it's important that the NAME show up in the 'Server:' response 
field.
Did you screw with that?

> I cleaned up a few logic things, but I tried my best not
>  to change any functionality.  

Did you break it?
Did you even test it to make sure?

What was submitted was heavily tested and worked fine.
If you broke it then I suggest putting it all back the way it was.

> I did, however, strip out the handling of
>  the deprecated commands... if they're deprecated, that can be documented,
>  but IMO there's no need to handle them just to print out an error that
>  says "this isn't supported anymore".  

I guess you haven't distributed many modules.

If you had, then you would understand that's it's easier
to just warn someone they have a mistake in their config
then to stop the Server cold.

I guess I really don't get this urge at Apache to have such
bare-bones code all the time that the users themselves
are the ones who suffer. 

My 2 cents.

> Where I had problems with/questions
>  about things, I put in an #error so I couldn't forget to take care of
>  them.  (They should be easily taken care of.)  Because of the #error
>  additions and the fact that I'm out of time to work on this for the day, I
>  haven't even tried compiling this, so there's the possibility I made some
>  stupid mistakes.  

I guess my only response to that is... Huh?
If you are going to butcher something you could at least
be a little careful about it. ( Re-compile/test as you make major
changes to be sure you are not breaking everything ).

> I'll get back to it later no doubt, but if someone else
> would care to take the next turn at looking over it, I'd appreciate it.
>  
>  To save bandwidth, my version is here:
>  http://www.apache.org/~jwoolley/mod_gzip.c
>  
>  --Cliff

I submitted that code and I said you (Apache) can do whatever
you like with it but I guess I didn't expect such an up-front
butcher job before anyone even had a chance to talk about
the code.

None of us needs any more aggravation than the ample supply
supply provided by the events of last week so I promise 
everyone I am not going to make any big deals about any
of this.

You have what you wanted ( Working/tested 2.0 filtering code 
prior to BETA ).

You ( Apache committers ) are going to do whatever you want no 
matter what I say, anyway, but I'll probably still keep shouting
a bit from the the back seat about potential wrong turns.

Just be careful. Unless you understand how the code really
works and why it makes some of the decisions it makes
think twice before getting out the chainsaw.

Yours...
Kevin Kiley



Reply via email to