On Wed, Sep 05, 2001 at 03:56:32AM -0400, [EMAIL PROTECTED] wrote:
> Greg Stein wrote...
>...
> > 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.
Generally, yes. But size matters :-) OpenSSL 0.9.6 isn't commonly
installed, but it is too big for us to include. (not to mention the general
crypto issues)
> I believe the other libs you mention have been 'tweaked'
> and that's another reason why the source is there, yes?
We try to avoid it. Speaking for Expat, any differnces from Expat's CVS is
simply because I haven't done the cross-patching needed yet.
> 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?
It certainly could, yes.
> > 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...
Until I learn differently, I'll trust that all the other zillions of zlib
users have ironed out the problems. At this point, I have no concrete
evidence that problems exist in zlib; just some FUD :-)
> > 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.
We don't always need votes to get a general feeling of people's thoughts on
various issues.
> Why note call for one?... not a vote on any particular piece of code
Because we don't need to. General consensus is supportive. We'll continue on
the assumption that *something* will go in, until somebody actually gets up
and vetoes it. But that probably wouldn't happen until we've selected mod_gz
or mod_gzip for what goes into Apache.
>...
> 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.
Ask him what he thinks now :-) Knowing Ryan, he is probably fine with
adding it at this point.
>...
> No one ( including myself ) has made any kind of airtight case
There is very little that goes into Apache nowadays that has an airtight
case. A general feeling of consensus implies we don't need it.
>...
> > 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.
Now you're just misconstruing what I said. I talked about your *approach*.
Your intent/hope to improve Apache is welcome and appreciated. But you
consistently aggravate people with how you approach and handle discussions.
>...
> > 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
Coding style is never a showstopper. When it goes it, we will make it fit
the Apache coding style. Just ask Ben Laurie what some of his contributions
look like now :-)
Yes, people have complained about stuff in mod_gzip 1.x, but don't
misinterpret that as a flat out veto.
> 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.
Of course. But people want to see mod_gzip 2.0, not the old one.
> 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.
The post the fucker already. Just what is your problem with posting it? If
you want us to integrate it, then why not post it NOW? Please explain.
>...
> 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.
As with the coding style, you are conflating acceptance of a module with
things that people will want to see changed. Just because people want
changes to be made doesn't mean they are flat out reject the *entire*
module.
When it goes into source control, people will:
* adjust the coding style to match Apache
* possibly strip unnecessary debug stuff
* strip out Apache 1.3 support since the code resides in the 2.0 repository
>...
> 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.
Nobody is asking you to. We're just asking that you post the module.
>...
> > 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.
And it was stopped. Simple as that.
> It was about to 'pass', I think. Why not start it over again and
> see if it actually does?
As I said before: people want to constrast/compare mod_gz against mod_gzip.
> 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?
Not always. In most cases, a majority rules, but the veto is absolute.
>...
> Finding any/all remaining problems with the filtering itself should be
> the real priority in this ALPHA stage, yes?
People work on what they will. Some people want to work on a gzip filter.
Some people want to work on stabilizing the server. To each their own. If
the "stabilizers" view the addition of mod_gz(ip) as destabilizing the
server, they might veto its introduction. But a new module really won't do
that, so each group can play in their areas without concern for the other.
> > 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.
See above (what people work on).
Also: beta happens when it happens. If the server isn't stable now, then it
will be later. If not then, then sometime after that. Sure, people are
impatient, but they only have a limited control over what other people can
do to the codebase. And they certainly cannot say how people "should" spend
their time.
> > 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.
Again: we want to compare/contrast to mod_gzip 2.0. And replacing modules is
*not* easy. I haven't seen it happen yet.
> > 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 misunderstand. I have confidence that mod_gzip, if you ever post the
damned thing, will be stable and require little work (other than the
"stylistic" things that I mentioned above, which people may want to do).
> 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.
When I said "we", I meant the people on this list. That includes you, but it
also includes the committers. If a committer changes an API, then it is
incumbent upon them to reflect that change throughout the codebase. In that
respect, they are assisting with the mod_gzip maintenance.
If there were no committers interested in maintaining mod_gzip, then yes:
you're right. It wouldn't ever go in, period. But I don't see that
happening.
[ altho some people are leery of maintaining a module with such a high
linecount, but I suspect a few are saying that without even seeing the
source code. ]
>...
> > * 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.
Explain why.
> > * 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.
I don't see how contributing mod_gzip 2.0 is related to your business. It
becomes the ASF's business once it goes into source control under our
copyright and license notice.
What I just plain don't understand at all is your reluctance to post the
source code to mod_gzip 2.0. Worse, you use it as a lever to say that mod_gz
is full of problems, yet it is a "secret" lever so your comments just appear
to be FUD.
Why not post the code? If you want mod_gzip in Apache, then post it. If
there is no way you're going to post it, then why this thread? Why are you
spending so much time with this?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
