In a message dated 01-09-15 16:34:59 EDT, Cliff wrote...
> > 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.
>
> <shrug> It mattered to me. I scratched an itch. No big thing.
Scratch away, then.
I just go the impression that it wan't all that important at this time.
> > > I also removed some more debug stuff (the r->notes things) since
> > > none of it ever seemed to be really used.
> >
> > 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.
>
> Okay, I didn't know that. It wasn't clear from the code that they were
> used elsewhere. I'll put them back.
See the mod_gzip forum and/or home page for 'compression analysis'
stuff. It's all based on the 'notes' interface'. Some people like to
create complete Custom logs that ONLY have the compression
statistics in them using the existing Apache LogFormat/Customlog
directives and what not.
I am not saying any of it has to stay. I am just giving you a 'heads up'.
Whatever you end with... I assure you that the ability to parse the
stats in the logs is going to be a requirement as it became
with mod_gzip 1.3.19.1a.
> > > 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.
>
> Huh? The license doesn't say that... does it? I read it several times
> and never got that impression. My interpretation was that if you
> distribute ZLIB (or a variant) itself, you must leave the license on
> _that_ code. So for example if we were distributing zutil.h, our version
> of zutil.h must retain the ZLIB license. Code that links with it is in a
> different category. I wasn't trying to disrespect the license, I just
> really didn't think it was supposed to be there.
>
> "If you use this software in a product, an acknowledgment in the product
> documentation would be appreciated but is not required."
>
> It's possible that I've misinterpreted that statement, of course...
You haven't misinterpreted it. Mark and Jean-loup's LIBPNG/ZLIB
license is about as 'don't care' as you get... but Mark is a friend
of mine and I guess I was just saying that I think Apache SHOULD
to the thing that he would 'appreciate'. If you are going to use his
code then give him ( and Jean-loup ) some credit.
That's all... no big whoop.
> > 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.
>
> No doubt.
The comments in the code submitted spelled it out.
Most binary downloads of ZLIB only have the ZLIB.H and
ZCONF.H header files so if you are going to require that
everyone already have their own ZLIB libraries to link
to ( Not recommended. See Dr. Mark Adlers comments
on this forum from a few days ago ) then the odds are
that they won't have ZUTIL.H and will have to suffer a
ZLIB source code distribution download anyway.
There are 3 ways around this...
1. Duplicate all the OS_CODE stuff from ZUTIL.H in the
module itself so there is no dependency.
2. Dump the ACTUAL OS_CODE stuff from the ACTUAL
ZUTIL.H right into the module. Again... no more dependency.
3. Include the latest/greates ZLIB source in the Apache tree
complete with Dr. Mark Adler's (private) patches that fix the
inflate() memory leaks and not only is there no dependency
for people to have the 'right' ZLIB you are sure to have the
best version available at all times in your Server. This is 'Best bet'
but is, of course, subject to a debate that will probably still
need to take place.
> > 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 didn't remove _all_ comments of course, not by a long shot. I just
> removed things that seemed really obvious and that we typically don't
> comment.
Roger that.
Whatever.
Rock on.
> > Sure... Whatever. I still think it's important that the NAME show up
> > in the 'Server:' response field.
>
> I just ripped out that whole line. I'll put the name part back, that's
> certainly reasonable.
It's a 'support' issue.
You will discover when bug reports start coming in that people
have no idea what is really running inside their Server unless
it 'announces' itself on the command line or as part of the
'Server:' field.
I am not saying that every module should 'name' itself in the
'Server:' field but I suggest you DO announce a module/filter
such as mod_gzip or people ( and your bug report handlers )
are going to get real confused about whether compression
is being handled by YOUR Server, or not.
Just my 2 cents and comes from my own 'I don't see the harm
in having it there but I do see the benefit' point of view.
> > What was submitted was heavily tested and worked fine.
> > If you broke it then I suggest putting it all back the way it was.
>
> If someone determines that I broke it (I'll test it myself later, just
> don't have time right now) and it's not obvious how to fix it, then feel
> free to ignore my changes. I just did it to save someone else the work
> because I think my changes make the code easier to grok for someone who's
> never looked at it before. It certainly helped me. I threw what I'd done
> out to the wolves prior to even bothering to test since like I said I
> don't have any more time for this today and I wanted to save someone else
> the work if they were thinking about doing anything similar. <shrug>
Roger that.
I really don't have a lot of the problems 'groking' code that I
keep hearing people complain about ( code is code is code )
so I guess I am always going to be in the 'why bother'
category on this one.
threw what I'd done
> I threw what I'd done out to the wolves prior to even bothering to test
> since like I said I don't have any more time for this today
Welcome to the wolf-pit, then.
Plenty of room.
> > ( I guess you haven't distributed many modules, then ).
> > 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.
>
> IMHO, version 2.0 already has big enough config changes that need to be
> made that people shouldn't expect to just drop in a 1.3 config. If all we
> have to say is "just delete this config line, it doesn't exist anymore,"
> then I tend to think that's sufficient. If this were a minor revision,
> clearly the story would be different since the principle of least
> astonishment applies more strongly. But maybe that's just me.
Not my call.
I just think it's more 'polite' to inform a non-technical user exactly
where they have made a mistake if/when it's possible to do that.
Hack 'em out, leave the helpful messages in, whatever.
Max nix to me.
> > 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.
>
> Like I said, I only did it because the end result was easier for me to
> understand. Take it or leave it. Nobody ever said that the fact that a
> derivative exists takes the original out of the running, for the obvious
> reasons that the original is heavily tested and so on. If someone else
> can even just use my version to read it through to more quickly understand
> what's going on in the original version (but use the original version)
> then I think it was worth it.
>
> --Cliff
I hear ya.
To each his own.
Yours...
Kevin
