On Mon, 3 Sep 2001, Peter J. Cranstone wrote:
> Marc,
>
> >> It makes zero sense to rush into doing "something" just to do
> "something" without any clear concept of where it is going >> or what
> steps really need to be taken to get there.
>
> Here's a concept.... Save bandwidth. Here's another one, it's part of
> the spec. Finally how about we released it under an ASF license.
That is irrelevant. We are talking about the proccess of doing something.
Just because something _may_ be desirable does NOT mean the proper
way to implement it is to jump into doing something "tomorrow"!
Sheesh.
The discussion is about adding support to Apache for sending output
using the gzip content encoding. There are various different ways
to do this, and there is not yet any clear consensus on what the best
way is. There are a number of issues that have been raised that do need
to be investigated before such a decision can be made.
Think then act, not the other way around.
> >> Also note that, IMO, we do _NOT_ want a mod_g* in 2.0 that has a lot
> of ugly support trying to make it function in 1.3.
>
> People around the world have been using mod_gzip on Apache 1.3.x for
> nearly a year. Kevin has supported the product. It has been stable since
> March. You've abandoned the 1.3.x people for 2.x which is getting closer
> to beta. As soon as it is you'll have a copy of mod_gzip for 2.x and we
> will support it.
Sorry, that isn't how it works. When 2.0 goes beta, we want to
start to _STOP_ adding features, instead of starting to add even
more. We (whenever I speak for "we", I mean me + my knowledge
acquired over the past x years of how things are done around here) will
_NOT_ release a product that is "Apache 2.0 + some third party module
bundled". The product will be "Apache 2.0". Either mod_gzip will
be an integrated part of that product in terms of development
process, etc. or it won't be there at all.
A module is not integrated into Apache by some third party saying "ok,
we will let you have this code when we think you are ready for it,
and then we will support it for you". A module is integrated into
Apache by the third party becoming a part of "us". I'm not sure you
have shown the interest in doing so or the ability to understand how
the development process works. That certainly doesn't mean we won't
consider your code, if you choose to make it available at a time in
the product development cycle where we still want to consider adding
such functionality, but it does mean that we would take the _code_,
at which point you could either find a way to participate in the ongoing
Apache development process, or not.
> >> I would also like to see more support for the claims that zlib is
> this horrible thing that just doesn't work properly in >> a huge number
> of ways, as tested by "the major internet testing companies" (whatever
> the heck that means).
>
> Sometimes I wonder where you've been.
Only sometimes? I always wonder where I've been...
> Mercury Interactive has about 60%
> of the market when it comes to Internet testing. EVERY and I mean EVERY
> person who is serious about benchmarking uses their Load Runner
Umh... maybe you haven't noticed, but there is more to the Internet
than the web.
Umh... maybe you haven't noticed, but there is a lot more to benchmarking
than what Load Runner can do.
So by "the major internet testing companies", do you mean Mercury
Interactive? "companies" is plural, so I assume there are others.
Is that true? Regardless, vague rumors are of no help. Do you
have any exact reference that talks about various issues with zlib
on a technical level?
> product... Which, guess what, has just been overhauled to SUPPORT
> content encoding GZIP which is being used by M$ in IIS 5.0 Guess why the
> overhauled it. Because people (large financial institutions) are using
> mod_gzip and Apache and IIS 5.0 and want to know if there is a
> difference in performance. As the link to those stats yesterday shows,
> there is indeed a BIG difference and as the latest NetCraft survey
> shows, Apache is falling every month while IIS gains. This is not a
> feature, this is PART OF THE SPEC and should have been included from the
> get go.
blah blah blah. It is a feature, pure and simple. There is NOTHING
in the HTTP/1.1 spec that says you must send content gzipped to be
unconditionally compliant with the spec. You do not advance your
argument with random marketoid babble, and I think we would be much
more receptive to what you are trying to say if you kept it to a
technical discussion.
> Apache is failing behind the curve. People want to save bandwidth. I
> don't really care if you include mod_gzip or not, the train has already
> left the station on this one. Soon it will be the majority who runs
> compression not the minority. If you don't believe me... Do a FTP search
> for sites that carry mod_gzip. You'll be surprised. Some very smart
> people have figured out that this is here to stay.
I'm glad that Apache has proven itself to be flexible enough to allow
people to add such functionality as a module if they desire it. After
all, that is what Apache is all about: letting users do what they want.
There are a lot of users of Apache, with many varying and sometimes
conflicting needs, which is why Apache has been designed with as much
flexibility as practical.
Hopefully in 2.0, it can be done a lot more easily than ever before due
to the architectural changes implemented to allow modules to do just this
sort of thing. Personally, I think that it may be appropriate to
add this type of functionality to 2.0 given better client support, given
better architectural support for this sort of thing in the server, given
the fact that we aren't yet in beta for 2.0. OTOH, perhaps it would
be better left for 2.1. Either way, I agree that it is worth considering.
BTW, trains tend to stop at a lot of stations, so if you miss it at one,
you can just catch it at the next, or catch the next train that will be
along any minute going to the same place.
