Marc,
Rather than continue this thread let's see if we can put this subject
into the end zone.
>> Think then act, not the other way around.
Then vote on it. Either +1 or -1 on including mod_gzip into the Apache
distribution.
Simple.
Peter.
PS. (If I remember rightly I think you already voted +1 on the license
for mod_gzip so this should be an easy decision)
-----Original Message-----
From: Marc Slemko [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 03, 2001 1:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Add mod_gz to httpd-2.0
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.
