Greg Stein wrote...
> > Kevin Kiley asked...
> >
> > What's it going to take to find out once and for all if
> > ZLIB can be included in the Apache source tree?
>
> It won't go in. No need for it. That hasn't been well-stated...
It has now, it seems ( finally! ).
Only takes one veto and looks like between you ( and/or Ryan )
there will never be any ZLIB sources in Apache. End of story.
Good to know.
> As stated elsewhere, pcre and expat are in there because they aren't
> typically available, like zlib is.
Ah... so that's the criteria? Ok.
I believe the other libs you mention have been 'tweaked'
and that's another reason why the source is there, yes?
What if you ever need to 'tweak' ZLIB because it was never
really designed to be a real-time data compression engine?
Would that remove the 'no ZLIB source' dictum?
> Nothing needs to happen, so it shouldn't be surprising :-). If/when we need
> it, then we will include it. As I said, it is just config macros.
You are putting an awful lot of faith in ZLIB and the assumption that it
will suit your needs 'out of the box' but I hear ya...
> There are three options on the table:
>
> 1) include mod_gzip
> 2) include mod_gz
> 3) include neither
>
> I believe there is consensus that (3) is not an option.
Huh?
I didn't see any real consensus on that.
Only a real vote will tell you that.
Why note call for one?... not a vote on any particular piece of code
but whether or not to include anything to do with IETF Content-Encoding
into the actual CORE or standard module base ( for now ).
That will tell the story about option 3 for sure.
Ryan himself said he prefers 3 right off the bat when Jerry
said 'Let's dump Ian's mod_gz into the core!' which is what
started this whole entire thread.
His (Ryan's) preference is that for the time being ( and I'm beginning to
lean that
way myself in light of this discussion ) is just leave the IETF
Content-Encoding
stuff out of the core and let 3rd party modules handle it. That'll work.
That's the way it works right now and thousands of real Apache users don't
seem to have a problem with that.
No one ( including myself ) has made any kind of airtight case
yet as to WHY IETF Content-Encoding support SHOULD be in
the core Server itself. I am not sure I could, at this point, after
seeing that anyone who really wants to compress responses
knows how to locate and install a module that will do so ( mod_gzip ).
I guess it would be easier for folks to 'get' it in the tarball but that
hasn't stopped
a few thousand people finding/using mod_gzip over the last year or so even I
have
to admit putting it all in the core doesn't seem like a house on fire.
> Despite yours and
> Peters pushing and stressing and overbearing "sell job" to get mod_gz(ip)
> type functionality into the core, it was just preaching to the choir. (well,
> okay: maybe Ryan didn't want to see it in there :-) That sell job mostly
> served to create an air of hostility.
Yea... okay... whatever... we are the 'bad guys' again for trying to
improve your Server. Mea Culpa.
> So now the question comes down to using (1) or (2). People are *not* voting
> on including mod_gz because they want to see your alternative. I think it
is
> pretty much that simple.
Yea... I guess.
> But then you say to look at the 1.3 version.
What I meant was... if anyone wants to see right away if a whole bunch
of pure 'coding style' bullshit is going to be the show stopper right off the
bat then there's no need to wait for anything. As I have said 3 times now...
it doesn't take rocket scientist to look at an existing module and imagine
what it will STILL look like with filtering calls in it.
I assure you... I did not rewrite the 1.3.x module just for 2.0. All I did
was add the filtering calls. It was no big deal.
Ian himself could have probably done the same in less time than it took
him to write the mod_gz demo in the first place.
I also haven't gotten an answer to my question regarding the weird comment
that appeared in this discussion about any module being submitted that
supports both 1.3.x AND 2.0 in the same code ( which the mod_gzip I have
here certainly does ) will be rejected for that reason alone.
Is that true?
If so... then this is all a moot point. I don't have the time at the moment
to hack up a perfectly fine module that supports ALL versions of Apache
into something that ONLY cares about Apache 2.0. I am not even
sure I would... it seems like a really stupid thing to do.
> Whether the changes are
> large or small, they'd rather see your current work because we already know
> the port has been completed and *tested*. We'd have to redo all of that
> work, which just seems silly.
Yep... sure would be.
> So the inclusion of either is blocked on seeing the source to mod_gzip for
> Apache 2.0.
Not really...
The vote about mod_gz was still in progress.
It was about to 'pass', I think. Why not start it over again and
see if it actually does?
Maybe a legal majority doesn't give a crap about seeing any
other code and would rather see Ian's mod_gz drop in the core right now.
Majority rules here, right?
I think Jerry's whole reason for saying 'let's go for it' was because he
is seeing screwy things trying to use a filter like mod_gz and mod_include
together and he wants to drop it in to have something to test with or
something like that. If dropping mod_gz in RIGHT NOW somehow helps
figure out the remaining filter problems then what the hell... go for it.
Finding any/all remaining problems with the filtering itself should be
the real priority in this ALPHA stage, yes?
> Now: you state that you don't want to release it until we hit beta. But
that
> is not how we work, and you should know that by now.
Sorry... I must have missed that part of the Apache developer's guide.
That is most certainly NOT how I thought you worked.
I thought the idea of adding new modules in the 11th hour before a
beta when you are still diagnosing I/O issues and/or multithreading
issues would have historically been a real downer for you guys.
> We want the module in there now, *before* beta hits.
Then fer chrissakes just drop Ian's demo in. It can be replaced
later if you find something better. You've done it before.
> You say that you don't want to release it
> while the APIs are in flux -- that they should be stable. But that is
bogus.
> If we include mod_gzip *today*, then it will get fixed along with
everything
> else as we change the APIs. You aren't going to be responsible for keeping
> it up to date with the changes. We are. That is part of what going into the
> core means -- that we have an obligation and responsibility to maintain it.
> And we will. If it goes in.
Okay... now you are blowing my mind.
Whenever we have tried to submit ANYTHING to you guys before all we got was
the direct opposite. If someone submitted a module in the next hour that
was the greatest thing since sliced bread but said 'I expect you to take this
as-is and not bother me anymore' you would normally just say 'yea... right...
get
outta town'.
You seem to be missing something here, Greg. If WE submit anything to
Apache and it is accepted then WE certainly plan on helping to maintain
it. If we feel ( as a company ) that we don't have the time to do so then
it's never going to darken your door. That's the way it is and the way I
have always understood the Apache (module) submission process to be.
> Summary:
>
> * zlib is not going to be included in any fashion, we'll use it by
reference
> if/when we need to
Roger that.
> * you should release your 2.0 mod_gzip so that everybody can make an
> informed decision about putting compression functionality into Apache
Agreed. It's the timing that is the only issue.
> * if mod_gzip goes in, then it would do so earlier rather than later, and
we
> will deal with any API changes that occur between now and ship -- it
isn't
> your burden to bear, so there shouldn't be a reason to withold.
We wanted a GA before we got involved with 2.0. That just makes
good business sense. Looks like that's still a LOOONG way off.
Then at least go BETA. Express confidence in your own product...
and you will see a lot of other submissions ( not just mod_gzip ).
Between BETA and SHIP you will get the chance to do whatever you
want... even pull things out.
If the upcoming beta ( WHEN?? ) absolutely MUST have a GZ filter
in the core ( for whatever reason that is ) then just go ahead and dump
Ian's demo in the core.
No one has even tested it enough to say whether it really works well or not...
but it just might!
Later...
Kevin
