RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Peter J. Cranstone]

>> The absolute best way to stay on top of API changes is to make your
code available to the people making those changes.

Rasmus... We don't want any distractions to the core code until it's
stable. It took 5-6 months to get mod_gzip stable for 1.3.x. I doubt it
will take that long in Apache 2.x but until it's stable why release
something which will could cause a problem.

Kevin and I have asked that mod_gzip be included in Apache 1.3.x because
it's stable, been tested by thousands of users and is part of the spec.
We'd like to repeat the same performance for 2.x


Peter

-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] 
Sent: Friday, September 07, 2001 12:08 AM
To: [EMAIL PROTECTED]
Subject: RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to
httpd-2.0)


> >> Why won't you post mod_gzip 2.0 *today*?
>
> Because Apache 2.x is not STABLE, not In BETA and the API set is not 
> yet FROZEN... When it is, we will release mod_gzip as a third party 
> module, which we will support and maintain.

I have stayed far away from this thread, but this just doesn't make any
sense to me.  The absolute best way to stay on top of API changes is to
make your code available to the people making those changes.  As soon as
we had an Apache2 PHP filter it was on our public CVS server and both
Doug and Ryan have tweaked it every now and then and many people have
tested it and found problems.  I don't understand how this could
possibly be a bad thing and definitely reduces the amount of
tail-chasing we will have to do later on.

-Rasmus

Re: [PATCH] Add mod_gz to httpd-2.0

[Ask Bjoern Hansen]

On Wed, 5 Sep 2001 [EMAIL PROTECTED] wrote:

[...]
> If you want to 'converse' with Peter then book a flight
> to Denver. This is EMAIL.

Well, D'oh!

The whole Apache Software Foundation is about people "conversing" -
and most of the time we just use email.  If you can't figure that
out, how should the httpd group be able to work with you?


 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
more than a billion impressions per week, http://valueclick.com

Re: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Graham Leggett]

"Peter J. Cranstone" wrote:

> Because Apache 2.x is not STABLE, not In BETA and the API set is not yet
> FROZEN... When it is, we will release mod_gzip as a third party module,
> which we will support and maintain.

Why not just release a beta of mod_gzip today for v2.0 and say that it
is not yet supported. At least you will have the benefit of some
exposure to make sure any problems are ironed out.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."
 S/MIME Cryptographic Signature

RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Gomez Henri]

>> Why won't you post mod_gzip 2.0 *today*?

>Because Apache 2.x is not STABLE, not In BETA and the API set is not yet
>FROZEN... When it is, we will release mod_gzip as a third party module,
>which we will support and maintain.

There is actually many alpha release, and many of then are more than beta
quality. IBM team started from a apache 2.0.18-beta to have their Apache 2.0
port for iSeries.

If you have a module INSIDE Apache you'll have more chance to
have some decision in API changes.

>In the meantime use mod_gz.

Frankly if mod_gz is included in apache core, it will be the de-facto
reference, and chance to have mod_gzip used will low

RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Peter J. Cranstone]

>> Why won't you post mod_gzip 2.0 *today*?

Because Apache 2.x is not STABLE, not In BETA and the API set is not yet
FROZEN... When it is, we will release mod_gzip as a third party module,
which we will support and maintain.

In the meantime use mod_gz.

Peter

-Original Message-
From: Greg Stein [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 10:34 PM
To: [EMAIL PROTECTED]
Subject: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to
httpd-2.0)


On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote:
> I suppose the only thing we can do is contribute. Kevin has, mod_gzip 
> was released under an ASF license which was approved by the ASF Board.

> If there is a hidden agenda there then you're better than I at 
> spotting it.
> 
> Mod_gzip is available for 1.3.x
> 
> It will be available for 2.x when you hit beta.
>...
> Now tell me where the hidden agenda is.

You and Kevin never answered my simple question:

Why won't you post mod_gzip 2.0 *today*?

I asked several times, but it never got answered. I seem to recall
somebody stating it was being held, pending stability of the internal
Apache APIs. But that isn't an issue if it is to be incorporated into
Apache.

Another response was "look at 1.3 and port it forwards to 2.0." Why
should that happen, when you've done the work? If you intend to
contribute it, then why the delay, making us repeat your work?

Without that simple question answered, then yes: I would think there is
some kind of hidden agenda. Avoiding that question, and not posting
mod_gzip 2.0 makes it appear that you are trying to hide something.

The more conspiratorial-minded of us would simply believe this whole
thread is to create a division and weaken the voting for mod_gz. Much
like politicians will introduce a second, similar bill to confuse and
divide supporters and then crush both bills. But of course that wouldn't
happen here, now would it? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

re: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Gomez Henri]

>You and Kevin never answered my simple question:
>Why won't you post mod_gzip 2.0 *today*?

Kevin, the best way to have mod_gzip in Apache 2.0 is to make 
it available. You knows i'm using it on Apache 1.3 for many times
and be more than happy to see such an excellent works on 2.0 :)

why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Greg Stein]

On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote:
> I suppose the only thing we can do is contribute. Kevin has, mod_gzip
> was released under an ASF license which was approved by the ASF Board.
> If there is a hidden agenda there then you're better than I at spotting
> it.
> 
> Mod_gzip is available for 1.3.x
> 
> It will be available for 2.x when you hit beta.
>...
> Now tell me where the hidden agenda is.

You and Kevin never answered my simple question:

Why won't you post mod_gzip 2.0 *today*?

I asked several times, but it never got answered. I seem to recall somebody
stating it was being held, pending stability of the internal Apache APIs.
But that isn't an issue if it is to be incorporated into Apache.

Another response was "look at 1.3 and port it forwards to 2.0." Why should
that happen, when you've done the work? If you intend to contribute it, then
why the delay, making us repeat your work?

Without that simple question answered, then yes: I would think there is some
kind of hidden agenda. Avoiding that question, and not posting mod_gzip 2.0
makes it appear that you are trying to hide something.

The more conspiratorial-minded of us would simply believe this whole thread
is to create a division and weaken the voting for mod_gz. Much like
politicians will introduce a second, similar bill to confuse and divide
supporters and then crush both bills. But of course that wouldn't happen
here, now would it? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-05 17:43:30 EDT, you write:

> From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]]
>  >Kiss my ass...
>  
>  *delurk*
>  
>  That'll motivate three +1's for mod_gz real quick. :^)
>  
>  (No need for anyone to reply. Just cluttering the list with sophomoric
>  humor.)
>  
>  -Charels

No problem, Charels...

This all just reminds me of some tense board meeting
and someone finally cracks a joke and the room breaks
out laughing. People are getting some things off their
chest here and that's a good thing.

It'll be back to business soon enough.

Later...
Kevin

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

[EMAIL PROTECTED] wrote:
> 
> Do you moonlight as a preacher or something?

Nope.

> Do you judge everyone around you like this?

Considering that it was an observation rather than a judgement,
I suppose I can say that yes, I make observations like that
all the time.

> If you want to 'converse' with Peter then book a flight
> to Denver. This is EMAIL. No one can ever say all
> they want to or exepct anyone to ever read it all.
> It's like 100 different pen-pal sessions going on at the
> same time.

Somehow the rest of us manage to communicate fairly well,
though.  Of course, sometimes we have to have face-to-face
meetings to clear up misunderstandings. :-)  And when someone
is asked a question, he generally answers, or at least does
not take offense when asked repeatedly.

> I've been reading this forum for 4 years and I certainly
> don't pretend that anyone here is 'my friend'.

Well, I think I am not alone in observing that some of the
people here *are* 'my friends.'  Why does it work for me
(and possibly others) and not you?

> This is business.

Peter made some statements and refused to clarify when
asked.  Sorry, but if that is business it doesn't sound
like *good* business to me.  But that is just my opinion,
and possibly worthless if it works for RC elsewhere.

It may be business to RC, but I think it probably is *not*
business for a lot of other people here.  Which might be the
basis for some of the disconnects.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

RE: [PATCH] Add mod_gz to httpd-2.0

[Charles Randall]

From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]]
>Kiss my ass...

*delurk*

That'll motivate three +1's for mod_gz real quick. :^)

(No need for anyone to reply. Just cluttering the list with sophomoric
humor.)

-Charels

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

[EMAIL PROTECTED] wrote:
> 
> In a message dated 01-09-05 14:16:59 EDT, Marc wrote...
> 
> > > After 3-4 years we know exactly how you work.
> >
> >  Oh?  Then what is the explanation for Kevin publicly soliciting
> >  an individual to do something that recent discussion has shown
> >  the group considers moot?
> 
> I asked him what he 'thought', asshole.
> 
> Are you seriously telling me you think I can't come onto this PUBLIC
> forum for a non-profit organization and ask someone what
> their opinon is?

My bad, then.  The "Ian... are you a committer? What do you say
about adding ZLIB to Apache source ASAP. Yea or nay?" sounded like
an incitement to me.  I apologise for misinterpreting it.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

[EMAIL PROTECTED] wrote:
> 
> In a message dated 01-09-05 16:14:01 EDT, you write:
> 
> > This is news to me, and certainly no permission has been
> >  given to either Compaq nor Covalent to call anything a
> >  'Compaq Apache server.'  I am on the ASF board and I
> >  can tell you this has not come before us.
> 
> Actually... it's called the 'Covalent Apache Web Server'.
> There isn't anything in your board meeting minutes that
> authorizes that, either.

If it says that anywhere on the product, or on Covalent's
or Compaq's sites, then the board will ask that it be changed.
However, if you are basing this solely on the C!NET article,
I do not think that it authoritative enough to warrant any
action at all; asking C!NET to clarify would not accomplish
much.  I do not think that either Covalent or Compaq are
using that name, however, and it is a non-issue if they are not.

I see Randy has already responded.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-05 16:40:22 EDT, you write:

> But you do have one thing partly right, IMO -- trying to converse
>  with you seems to frequently be an exercise in futility.  That
>  is a social issue, and if the rest of the group cannot have
>  a reasonable conversation with a module developer, no technical
>  merit of the module is going to overcome the irritation and
>  frustration the rest of the group is going to experience if
>  it gets included.

Do you moonlight as a preacher or something?
Do you judge everyone around you like this?

If you want to 'converse' with Peter then book a flight
to Denver. This is EMAIL. No one can ever say all
they want to or exepct anyone to ever read it all.
It's like 100 different pen-pal sessions going on at the
same time. I've been reading this forum for 4 years
and I certainly don't pretend that anyone here is 'my friend'.

This is business.

Later...
Kevin

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

[EMAIL PROTECTED] wrote:
> 
> In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote...
> 
> > This is not technical, this is social and political.
> 
> Then keep it off the forum... you fucking didactic
> self-righteous asshole.

As I said, invective time.  As I also said, except to Peter
alone, you are showing a definite talent for changing my
opinion toward RC from 'wary' to 'hostile.'  I guess you are
now included..

Sorry to disappoint you, but it *belongs* in this forum.  Whether
the group as a whole can get along with you, or cannot, is
extremely relevant.

> When was the last fucking time you posted anything useful?

'What have you done for me lately', eh?  And the relevance is..?
I have been busy with ApacheCon, so I guess I am not entitled
to have an opinion on technical matters any more?  Or on
how the project operates?

> Send your 'social and political' commentary to us privately.
> You know where we are.

That would be pointless, since I would only be expressing my
own opinions and you would be the only ones to tell me I
was wrong (if I were, and I may be).  Stalemate.  Here everyone
has a chance to comment.

I have been willing to cut you guys slack from the beginning,
but that ends now.  Get along with the people here, or go away.
That is my opinion.

> BTW: Seen the latest press release regarding Covalent and Compaq?
> Any comments for those boys?

Yep; read my other replies in this thread.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-05 16:14:01 EDT, you write:

> This is news to me, and certainly no permission has been
>  given to either Compaq nor Covalent to call anything a
>  'Compaq Apache server.'  I am on the ASF board and I
>  can tell you this has not come before us.

Actually... it's called the 'Covalent Apache Web Server'.
There isn't anything in your board meeting minutes that
authorizes that, either.

Not complaining... just pointing out a fact.
I am with Peter on this. More power to them.

Randy Terbrush hasn't appeared here for awhile but there
is no question he should benefit financially from his early
work with Apache. Ryan and Dirk and Harrie and Doug and 
Daniel and Jon and Bill Wrowe ( others?... Apache contibutors
all ) deserve the same. I hope they all get to buy their own
private island following the recent Compaq deal the timing of
which was perfect since the valuation of the jsut announced
Compaq and Hewlett-Packet merger is in the neighborhood
of 25 BILLION ( With a B ) dollars.

Again... more power to all.
Randy and William Rowe alone have busted their ASSES
trying to give you 2.0. I hope they both get private jets
out of the deal.

Later...
Kevin Kiley

RE: [PATCH] Add mod_gz to httpd-2.0

[Randy Terbush]

> "Peter J. Cranstone" wrote:
> >
> > It was on a recent CNET release:
> > http://news.cnet.com/news/0-1003-200-6963955.html
> >
> > "" Compaq Computer has signed a deal with Covalent Technology
> > to jointly develop and market Covalent's Apache Web server
> > software, the companies plan to announce Monday. ""
>
> Thank you for the reference.  Yes, that is phrased ambiguously;
> it can either be taken as Covalent owning Apache, or Covalent's
> software *for* Apache.  I expect Ryan will have someone contact
> C!NET about it.

Ryan has way more productive things to spend his time on...

I am happy to chase down any document, under the control of Covalent, that
needs wordsmithing. I am not willing to take on the chore of correcting
other people's works. All members of Covalent staff both with and without
ASF affiliations spend a fair amount of their time keeping our marketing
material represpentative of the truth and spirit of our relationship with
the ASF. I think that anyone who knows me or any other person at Covalent
can vouch for that fact.

There are plenty of other less ambiguous examples of "violations" regarding
Apache and product relationships on the net. Please don't paint Covalent in
that same light.

-Randy


> --
> #ken  P-)}
>
> Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
> Author, developer, opinionist  http://Apache-Server.Com/
>
> "All right everyone!  Step away from the glowing hamburger!"
>

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-05 14:16:59 EDT, Marc wrote...

> > After 3-4 years we know exactly how you work.
>  
>  Oh?  Then what is the explanation for Kevin publicly soliciting
>  an individual to do something that recent discussion has shown
>  the group considers moot?

I asked him what he 'thought', asshole.

Are you seriously telling me you think I can't come onto this PUBLIC
forum for a non-profit organization and ask someone what
their opinon is?

Give me a fucking break.

Yours...
Kevin Kiley
  

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote...

> This is not technical, this is social and political.

Then keep it off the forum... you fucking didactic self-righteous asshole.
When was the last fucking time you posted anything useful?

Send your 'social and political' commentary to us privately.
You know where we are.

Yours...
Kevin Kiley

BTW: Seen the latest press release regarding Covalent and Compaq?
Any comments for those boys?

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

"Peter J. Cranstone" wrote:
> 
> Kiss my ass...

And now to the invective.

> I have work to do.

Which apparently does not include answering questions about
your previous posts.  Well, you did answer one of the ones
about the 'Compaq Apache Server' thing, so thanks for that.

> You want to continue the conversation
> take it off line you know where I am.

No, thanks.  I have nothing to hide, so I will keep my remarks
and responses right here in the public eye.  If you have
something you want to say privately, you can send to *me* offline,
and I will keep it private.

You know, you are showing a definite talent for moving me from
'wary' to 'hostile.'
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

"Peter J. Cranstone" wrote:
> 
> It was on a recent CNET release:
> http://news.cnet.com/news/0-1003-200-6963955.html
> 
> "" Compaq Computer has signed a deal with Covalent Technology
> to jointly develop and market Covalent's Apache Web server
> software, the companies plan to announce Monday. ""

Thank you for the reference.  Yes, that is phrased ambiguously;
it can either be taken as Covalent owning Apache, or Covalent's
software *for* Apache.  I expect Ryan will have someone contact
C!NET about it.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

Ken,

Kiss my ass... I have work to do. You want to continue the conversation
take it off line you know where I am.


Peter

-Original Message-
From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 2:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


"Peter J. Cranstone" wrote:
> 
> Conversation is over. I have nothing more to add. This whole 
> conversation is degenerating into meaningless nonsense.
> 
> Someone else can carry the thread.

This clever technique of ducking out of the conversation rather than
answering pointed questions is just *so* endearing, Peter. And it is one
of the tactics to which I alluded earlier as making me wary of your
motives.  You bring something up, we question you about it, you say the
conversation is meaningless. You made remarks, statements, and
allegations -- stand up to them.

As for 'nothing more to add' -- well, you could add the answers to the
questions you have been asked..

But you do have one thing partly right, IMO -- trying to converse with
you seems to frequently be an exercise in futility.  That is a social
issue, and if the rest of the group cannot have a reasonable
conversation with a module developer, no technical merit of the module
is going to overcome the irritation and frustration the rest of the
group is going to experience if it gets included.

So, in short, if you have any interest in mod_gzip being included, stop
behaving like an ass and *converse*.  'Conversation over,' forsooth!
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

"Peter J. Cranstone" wrote:
> 
> Conversation is over. I have nothing more to add. This whole
> conversation is degenerating into meaningless nonsense.
> 
> Someone else can carry the thread.

This clever technique of ducking out of the conversation rather
than answering pointed questions is just *so* endearing, Peter.
And it is one of the tactics to which I alluded earlier as
making me wary of your motives.  You bring something up, we
question you about it, you say the conversation is meaningless.
You made remarks, statements, and allegations -- stand up to
them.

As for 'nothing more to add' -- well, you could add the answers
to the questions you have been asked..

But you do have one thing partly right, IMO -- trying to converse
with you seems to frequently be an exercise in futility.  That
is a social issue, and if the rest of the group cannot have
a reasonable conversation with a module developer, no technical
merit of the module is going to overcome the irritation and
frustration the rest of the group is going to experience if
it gets included.

So, in short, if you have any interest in mod_gzip being included,
stop behaving like an ass and *converse*.  'Conversation over,'
forsooth!
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

>> If somebody does find that name as a product anyplace, please let me
know ASAP.

It was on a recent CNET release:
http://news.cnet.com/news/0-1003-200-6963955.html

"" Compaq Computer has signed a deal with Covalent Technology to jointly
develop and market Covalent's Apache Web server software, the companies
plan to announce Monday. ""


-Original Message-
From: Ryan Bloom [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 2:27 PM
To: [EMAIL PROTECTED]; Rodent of Unusual Size
Subject: Re: [PATCH] Add mod_gz to httpd-2.0



> > From a political standpoint I'm pissed that Covalent Technologies 
> > can cut a deal with Compaq for the new Compaq Apache server (wonder 
> > if it will ship with or without compression (details are tough to 
> > find on this whole deal).
>
> This is news to me, and certainly no permission has been given to 
> either Compaq nor Covalent to call anything a 'Compaq Apache server.'

> I am on the ASF board and I can tell you this has not come before us.

I should point out that AFAIK, "Compaq Apache server" is not a product
name that I have ever heard before.  A quick look at Compaq's web site
also does not come up with that name anywhere.

If somebody does find that name as a product anyplace, please let me
know ASAP.  However, Covalent knows very well what we can and can not
call products, so I can't imagine that we would use that name.

Ryan __
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

> > From a political standpoint I'm pissed that Covalent
> > Technologies can cut a deal with Compaq for the new
> > Compaq Apache server (wonder if it will ship with or
> > without compression (details are tough to find on this
> > whole deal).
>
> This is news to me, and certainly no permission has been
> given to either Compaq nor Covalent to call anything a
> 'Compaq Apache server.'  I am on the ASF board and I
> can tell you this has not come before us.

I should point out that AFAIK, "Compaq Apache server" is not a
product name that I have ever heard before.  A quick look at
Compaq's web site also does not come up with that name anywhere.

If somebody does find that name as a product anyplace, please
let me know ASAP.  However, Covalent knows very well what we
can and can not call products, so I can't imagine that we would
use that name.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

Guys,

Conversation is over. I have nothing more to add. This whole
conversation is degenerating into meaningless nonsense. 

Someone else can carry the thread.


Peter

-Original Message-
From: Thomas Eibner [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 2:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


Okay, I'll bite.

On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote:
[Snip: nothing that hasn't been said in this thread before]
>
> If it's not technical, then it's social (you just plain don't like 
> us... Not a problem) or political (the powers that be don't like us...

> Again not a problem)
> 
> >From a political standpoint I'm pissed that Covalent Technologies can
> cut a deal with Compaq for the new Compaq Apache server (wonder if it 
> will ship with or without compression (details are tough to find on 
> this whole deal). But you know what, more power to Ryan and his crew 
> for doing something like that. Did I ever see a vote for something 
> like that, no... I even checked the ASF minutes... Nothing since 
> February. Whatever.

Why are you dragging this into the discussion? I can't see that it has
anything to do with it. Anyone else seeing this as a bad thing for 
Apache?

I don't see why they shouldn't be allowed to do this, anyone should be
able to do this, even your company. But do you have the expertise?

Looking at the License of Apache it doesn't make it sound like they
wouldn't be able to do so, as long as they state like written in the
license: "This product includes software developed by the Apache Group
for use in the Apache HTTP server project (http://www.apache.org/)."
Which I am quite sure they will, Covalent will probably use every chance
they get to promote Apache.

The reason why there might not be more information on this deal than
what Covalents website gives[1] might be that the rest is to be worked
out?

When I heard this I was kind of happy for Apache, 'cause it can only be
a good thing if Covalent gets a deal like this. More money, more likely
that Ryan, Randy, Dough, William, etc. will keep up their very good work
on Apache.

my $cent = 2;

[1] http://www.covalent.net/company/press/news-20010828.php

-- 
  Thomas Eibner

Re: [PATCH] Add mod_gz to httpd-2.0

[Thomas Eibner]

Okay, I'll bite.

On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote:
[Snip: nothing that hasn't been said in this thread before]
>
> If it's not technical, then it's social (you just plain don't like us...
> Not a problem) or political (the powers that be don't like us... Again
> not a problem)
> 
> >From a political standpoint I'm pissed that Covalent Technologies can
> cut a deal with Compaq for the new Compaq Apache server (wonder if it
> will ship with or without compression (details are tough to find on this
> whole deal). But you know what, more power to Ryan and his crew for
> doing something like that. Did I ever see a vote for something like
> that, no... I even checked the ASF minutes... Nothing since February.
> Whatever.

Why are you dragging this into the discussion? I can't see that it has
anything to do with it. Anyone else seeing this as a bad thing for 
Apache?

I don't see why they shouldn't be allowed to do this, anyone should be
able to do this, even your company. But do you have the expertise?

Looking at the License of Apache it doesn't make it sound like they
wouldn't be able to do so, as long as they state like written in the
license: "This product includes software developed by the Apache Group
for use in the Apache HTTP server project (http://www.apache.org/)."
Which I am quite sure they will, Covalent will probably use every chance
they get to promote Apache.

The reason why there might not be more information on this deal than
what Covalents website gives[1] might be that the rest is to be worked
out?

When I heard this I was kind of happy for Apache, 'cause it can only be
a good thing if Covalent gets a deal like this. More money, more likely
that Ryan, Randy, Dough, William, etc. will keep up their very good work
on Apache.

my $cent = 2;

[1] http://www.covalent.net/company/press/news-20010828.php

-- 
  Thomas Eibner

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

"Peter J. Cranstone" wrote:
> 
> If there is a hidden agenda there then you're better than I
> at spotting it.
:
> Now tell me where the hidden agenda is.

If there were one, I would not be able to tell you because a) it
would be hidden, and b) it would be *your* agenda, not mine.
As it is, I do not know if there is one or not.

> If it's not technical, then it's social (you just
> plain don't like us... Not a problem)

Not so.  Social and political issues can prevent technically
valid things from happening.  So it *could* be a problem,
and may be.  That you think it would not be a problem
does not help.

> From a political standpoint I'm pissed that Covalent
> Technologies can cut a deal with Compaq for the new
> Compaq Apache server (wonder if it will ship with or
> without compression (details are tough to find on this
> whole deal).

This is news to me, and certainly no permission has been
given to either Compaq nor Covalent to call anything a
'Compaq Apache server.'  I am on the ASF board and I
can tell you this has not come before us.

> But you know what, more power to Ryan and his crew for
> doing something like that.

What are you whinging about?  Nothing prevents RC from entering
into a deal with Compaq or anyone else to ship mod_gzip.
If you are upset about the use of the word 'Apache' in this
news-to-me deal, it is misplaced -- because no such name has
been approved by the ASF.

> Did I ever see a vote for something like that, no...

What are thinking would be voted on?  The name, or permission
for Covalent to make a deal with Compaq?  The former would be,
but has not come up; the latter is no-one's business but Compaq's
and Covalent's.

> This whole conversation is mute, include, exclude, revoke
> whatever, mod_gzip will always be available from Kevin and
> I and we will support it.
> 
> If you don't include it, all it means is another click to
> our website.

Then what is your motivation for trying to get it into the
Apache distribution?  I am not being snide, I am asking
seriously.  I suspect it is to get the marketing bulge of
being able to say it is there, which is fine -- have I guessed
correctly?  AFAIC that is a perfectly valid reason, although
making it happen requires an informal social contract with the
AG -- which is where a lot of problems seem to lie.

> Later...

I notice you failed to answer the question I posed you.  Just
in case they were overlooked, here it is again:

> "Peter J. Cranstone" wrote:
> >
> > After 3-4 years we know exactly how you work.
> 
> Oh?  Then what is the explanation for Kevin publicly
> soliciting an individual to do something that recent
> discussion has shown the group considers moot?
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

I really should just ignore this.  But oh well

> From a political standpoint I'm pissed that Covalent Technologies can
> cut a deal with Compaq for the new Compaq Apache server (wonder if it
> will ship with or without compression (details are tough to find on this
> whole deal). But you know what, more power to Ryan and his crew for
> doing something like that. Did I ever see a vote for something like
> that, no... I even checked the ASF minutes... Nothing since February.
> Whatever.

a)  This is not Ryan and his crew.  I am an engineering manager at Covalent.
I have 0 control over partnerships and the like.

b)  Why does this deal piss you off?  Covalent and Compaq are partnering to
promote the use of Apache and Compaq hardware with Linux in the 
marketplace.  They were looking for an company to partner with to help, and for
Apache that was us.

c)  Right now, the solution does not include compression at all.  That may
change in the future, but I don't know of any plans along those lines.

d)  This has nothing to do with the ASF, so the ASF wasn't involved.  Covalent
sells a version of Apache (with only EAPI patches applied), and proprietary 
modules.  We do not need to check with the ASF to partner with a company that
wants our help to do the same basic thing.  If RemoteCommunications wants to
sell Apache, feel free, you don't need ASF permission to do so.  You do need
to follow the license, which Covalent does.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

I suppose the only thing we can do is contribute. Kevin has, mod_gzip
was released under an ASF license which was approved by the ASF Board.
If there is a hidden agenda there then you're better than I at spotting
it.

Mod_gzip is available for 1.3.x

It will be available for 2.x when you hit beta.

It will contain the same license as before.

There are no patents, TM's or anything else associated with it.

We will continue to support both versions.

Now tell me where the hidden agenda is. 

If it's not technical, then it's social (you just plain don't like us...
Not a problem) or political (the powers that be don't like us... Again
not a problem)

>From a political standpoint I'm pissed that Covalent Technologies can
cut a deal with Compaq for the new Compaq Apache server (wonder if it
will ship with or without compression (details are tough to find on this
whole deal). But you know what, more power to Ryan and his crew for
doing something like that. Did I ever see a vote for something like
that, no... I even checked the ASF minutes... Nothing since February.
Whatever.

This whole conversation is mute, include, exclude, revoke whatever,
mod_gzip will always be available from Kevin and I and we will support
it.

If you don't include it, all it means is another click to our website.

Later...


Peter



-Original Message-
From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 12:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


"Peter J. Cranstone" wrote:
> 
> After 3-4 years we know exactly how you work.

Oh?  Then what is the explanation for Kevin publicly soliciting an
individual to do something that recent discussion has shown the group
considers moot?

Regardless of facts, it is perception that matters.  Not speaking for
anyone else, my perception of the practises in which you and Kevin have
seemingly engaged makes me personally wary and unwilling to take
anything you write at face value.  Little things, like Kevin's post just
now, and the multiplicity of 'I'm not with RC' mail origins a couple of
years ago, and the overall tenor of your posts..

I try very hard to keep an open mind; when I committed to you to get you
a session at ApacheCon to talk about generic content compression issue,
I meant it -- but was overruled 4 to 1. Despite my best efforts at
open-mindedness, something about your collective tactics and polemic
keeps making me want to close my mind against you.  And I suspect (but
do not know) that others have the same perception, which may have been
the cause of that 4-1 vote.

Most people I take at face value -- but you seem to change positions so
much that I feel I cannot but suspect you of having a hidden agenda.
Maybe you do not, and maybe you do -- and maybe it is no more than
trying to get RC's package into the Apache distribution because of the
marketing bulge that would give RC.  But.. maybe it is more than that.
I cannot tell, and you have not made it easy to tell, and I am not sure
I would blindly accept it if you did.

This is not technical, this is social and political.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

"Peter J. Cranstone" wrote:
> 
> After 3-4 years we know exactly how you work.

Oh?  Then what is the explanation for Kevin publicly soliciting
an individual to do something that recent discussion has shown
the group considers moot?

Regardless of facts, it is perception that matters.  Not speaking
for anyone else, my perception of the practises in which you and
Kevin have seemingly engaged makes me personally wary and unwilling
to take anything you write at face value.  Little things, like
Kevin's post just now, and the multiplicity of 'I'm not with RC'
mail origins a couple of years ago, and the overall tenor of
your posts..

I try very hard to keep an open mind; when I committed to you to
get you a session at ApacheCon to talk about generic content
compression issue, I meant it -- but was overruled 4 to 1.
Despite my best efforts at open-mindedness, something about your
collective tactics and polemic keeps making me want to close my
mind against you.  And I suspect (but do not know) that others
have the same perception, which may have been the cause of that
4-1 vote.

Most people I take at face value -- but you seem to change positions
so much that I feel I cannot but suspect you of having a hidden
agenda.  Maybe you do not, and maybe you do -- and maybe it is
no more than trying to get RC's package into the Apache distribution
because of the marketing bulge that would give RC.  But.. maybe
it is more than that.  I cannot tell, and you have not made it
easy to tell, and I am not sure I would blindly accept it if you
did.

This is not technical, this is social and political.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

After 3-4 years we know exactly how you work.


Peter

-Original Message-
From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 05, 2001 11:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


[EMAIL PROTECTED] wrote:
> 
> Ian... are you a committer?
> What do you say about adding ZLIB to Apache source ASAP.
> Yea or nay?

This only demonstrates your non-understanding of how we work, and/or how
to work with us.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

[EMAIL PROTECTED] wrote:
> 
> Ian... are you a committer?
> What do you say about adding ZLIB to Apache source ASAP.
> Yea or nay?

This only demonstrates your non-understanding of how we work,
and/or how to work with us.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

On Tuesday 04 September 2001 18:23, Greg Stein wrote:
> On Mon, Sep 03, 2001 at 05:47:02PM -0700, Ryan Bloom wrote:
> >...
> > I have a big problem with this.  We had a hard enough time contributing
> > patches back to MM.  The only reason we keep expat and pcre up to date,
> > is that we NEVER make any changes to them.  I would be very much against
> > adding zlib to our tree.
>
> Not to mention that I'm also an Expat developer, so I can cross-port
> changes back and forth between the trees. :-)
>
> But yes: the stability of PCRE and Expat are a big help. However, I'd point
> out that we didn't make a lot of changes to MM either; it was quite stable,
> too. No idea why the changes didn't go back and forth, tho.

We actually made a lot of changes to MM.  Which is also why the changes
didn't go back and forth.  We needed things that Ralf didn't want to put in
the MM dist.  Once we weren't exactly the same, the patching just fell
apart.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[Ian Holsman]

[EMAIL PROTECTED] wrote:

> In a message dated 01-09-04 19:17:25 EDT, Ian writes...
> 
> 
>>>ASIDE: You really only need the 'compression' part of it. You
>>>
>> > are a Server, not a client.
>> 
>> we also can be a client.
>> think mod-proxy
>>
> 
> What current ( or future ) operation would require mod_proxy
> to 'decompress' something? I would imagine that if mod_proxy
> can ever accept Content-Encodings it would do what SQUID
> does... it just stores the response and pays attention to the
> 'Vary' headers and such but there's never a need to 'decompress' 
> anything.
> 

I was thinking that the proxy could request gzip'd data, and possibly
get gzip'd returned. it would then examine the client's request and
if it can't handle a gzip reply it would ungzip it.

(this is the approach that rsync's rproxy takes.)

the proxy also reverse-proxies, and the output of that needs to be
plain text so it could be merged (via mod-include) (and then possibly
gzip'd again)

I'm going to run mod_gz through our benchmark lab tomorrow (8-way machine)

to see what happens (CPU Usage mainly,and to see if there are any resource leaks)
If I get a copy of mod_gzip for 2.0 I will do the same for it.


> Maintaining an 'object compression' cache is a bit different from
> regular caching and has to follow different 'rules'. Even if there is
> a way to store both a compressed and non-compressed version
> of the same URL in a cache there still isn't any real need to
> 'decompress' anything.
> 
> Transfer-encoding: gzip, chunked  or some other 'hop to hop' deal
> is a different story but there's still no known browser that can handle 
> that ( nor any known Proxy that can, either, AFAIK ).
> 

check out the work being down by the rproxy.samba.org on rproxy.
if we had rsync compression (and a proxy to un-rysnc it) it would be
really cool... (especially if mozilla could talk rproxy) but that is
pie in the sky.


> It was just a thought.
> If people think that ZLIB is 'too big' you can easily cut it in
> half by only including what you need.
> 

nah... I'd rather just link to the one already living on people's systems.

the only advantage is if apache's memory pool handling is much faster than
zlibs plain old malloc.. but I'm not sold on that (we could link in hoard)


> Ian... are you a committer?

not on Apache, just APR & Proxy


> What do you say about adding ZLIB to Apache source ASAP.
> Yea or nay?
> 
> Yours...
> Kevin Kiley
> 

..Ian

the rollup issue (was: Re: [PATCH] Add mod_gz to httpd-2.0)

[Greg Stein]

On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote:
>...
> 3)  I don't believe that we
> should be adding every possible module to the core distribution.  I
> personally think we should leave the core as minimal as possible, and
> only add more modules if they implement a part of the HTTP spec.

The list has already covered the "minimalist" thing, but the rollup issue is
still outstanding.

A suggestion: create httpd-rollup to hold the tools/scripts/web pages and
whatnot for creating a combo of httpd releases plus supporting modules.

The -rollup project could create rollups of just ASF bits (proxy and ???),
but could also be a way to rollup third-party modules (like Ralf's module
bundles). I believe we have also discussed how the Apache Toolbox could
become an ASF project. I'd suggest that it goes into httpd-rollup as one of
its "outputs".

For example:

  /home/cvs/httpd-rollup
contrib-1.3/Apache 1.3 plus a bunch of contrib modules
toolbox/Apache Toolbox
asf-2.0/Apache 2.0 plus ASF bits
contrib-2.0/Apache 2.0 plus ASF plus contribs
...

Under httpd-site, we'd create the /rollup/ subdirectory and tightly
incorporate references to it with our distribution pages (to ensure that the
blob with proxy in it is just as easy to find/download as the core).

Does this seem like a reasonable approach to get out of the rollup logjam?
Given this kind of arrangement, would some module contributions or inclusion
have a "lower bar" to become part of ASF-distributed bits? etc.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

patch comments Re: [PATCH] Add mod_gz to httpd-2.0

[Greg Stein]

On Sat, Sep 01, 2001 at 02:56:45PM -0700, Justin Erenkrantz wrote:
>...
> I told him I'd look at it a while ago, but never got a chance to do 
> so.  So, I spent this morning cleaning up the configuration and a bit 
> of the code to fit our style (nothing major).

You shouldn't have to do that. Ian should, and he must learn to deal with it
if he wants to continue contributing. We all learn different habits to work
in this group.

> I'd like to add this to the modules/filters directory (which seems
> like the most appropriate place).

Yes.

>...
> We could remove GZFilter as it really serves no purpose as well as the 
> text/html check in mod_gz.

s/could/should/

I agree that it doesn't make sense to be in there. We should be using more
consistent mechanism to handle filter inclusion and management. One-off
commands here and there are simply serving to make the filter system more
complicated.

> I'd like to commit something that is close
> to what Ian originally submitted and then tweak it slightly.

Push it back to him to tweak. It appears we have a bit of time :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] Add mod_gz to httpd-2.0

[Greg Stein]

On Mon, Sep 03, 2001 at 05:47:02PM -0700, Ryan Bloom wrote:
>...
> I have a big problem with this.  We had a hard enough time contributing
> patches back to MM.  The only reason we keep expat and pcre up to date,
> is that we NEVER make any changes to them.  I would be very much against
> adding zlib to our tree.

Not to mention that I'm also an Expat developer, so I can cross-port changes
back and forth between the trees. :-)

But yes: the stability of PCRE and Expat are a big help. However, I'd point
out that we didn't make a lot of changes to MM either; it was quite stable,
too. No idea why the changes didn't go back and forth, tho.

In fact, the ASF has been a very good influence on Expat. Our ideas are
being used for its config/build setup. A lot of the portability work and
research that the ASF is good for, is being reflected into Expat to ensure
that it is just as portable.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-04 19:17:25 EDT, Ian writes...

> > ASIDE: You really only need the 'compression' part of it. You
>  > are a Server, not a client.
>  
>  we also can be a client.
>  think mod-proxy

What current ( or future ) operation would require mod_proxy
to 'decompress' something? I would imagine that if mod_proxy
can ever accept Content-Encodings it would do what SQUID
does... it just stores the response and pays attention to the
'Vary' headers and such but there's never a need to 'decompress' 
anything.

Maintaining an 'object compression' cache is a bit different from
regular caching and has to follow different 'rules'. Even if there is
a way to store both a compressed and non-compressed version
of the same URL in a cache there still isn't any real need to
'decompress' anything.

Transfer-encoding: gzip, chunked  or some other 'hop to hop' deal
is a different story but there's still no known browser that can handle 
that ( nor any known Proxy that can, either, AFAIK ).

It was just a thought.
If people think that ZLIB is 'too big' you can easily cut it in
half by only including what you need.

Ian... are you a committer?
What do you say about adding ZLIB to Apache source ASAP.
Yea or nay?

Yours...
Kevin Kiley

Re: [PATCH] Add mod_gz to httpd-2.0

[Ian Holsman]

On Tue, 2001-09-04 at 12:29, [EMAIL PROTECTED] wrote:
> 
> 
> ASIDE: You really only need the 'compression' part of it. You
> are a Server, not a client.

we also can be a client.
think mod-proxy

..The Weekend Warrior
> 
> Yours...
> Kevin Kiley
-- 
Ian Holsman  [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-04 12:39:44 EDT, Guenter writes...

> > Guenter Knauf wrote...
>  
>  >> Hi,
>  >> I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32
>  >> and it works for me.
>  > What did you test?
>  that it compiles, loads into server and compresses.
>  > How 'heavily loaded' was the Server?
>  you're right, I did only a quick test with some huge text pages; and I 
didnt 
> compare against your mod_gzip; but real comparing isnt possible yet because 
> then I have to compare also Apache 1.3 with 2.0: I dont have your 2.0 gzip 
> module.

I wasn't asking if you had tested mod_gzip... You said you had
tested 'mod_gz' and that 'it worked' and I was just curious what
you were calling 'success'. You don't even say what MIME 
type you tested. text/plain or text/html? Did you try anything
else and did you try it under real circumstances like a fully
loaded Server?

[rest of message snipped]

Guenter... the rest of the message really should have been
sent to the mod_gzip forum. Check the title of this message
thread... it really concerns someone suggesting that a 
filtering demo called 'mod_gz' be added to the Apache 
base tarball. This is not really 'about' mod_gzip at all.

I WILL address every point you raised and I will check
my notes... I am SURE someone else found the answer
as to why Novell's version of Apache is not a standard
'distribution' of Apache and doesn't 'behave' the way 
'normal' Apache does. I will locate the info and send it
to you. It may be that you have to get the patch from
Novell since it's only their 'altered' version of Apache
that isn't playing by the rules ( Actually... IBM's rewrite
falls into same category but that's not your concern ).

Please direct any further mod_gzip 'support' questions to
either the mod_gzip forum or to myself. mod_gzip is not
part of Apache and these guys are going to explode if
this 'please support my Netware' discussion goes any
farther on this forum under this message thread.

Yours...
Kevin Kiley

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-04 09:35:50 EDT, Jim wrote...

> >That's right and one of them is...
>  >
>  >Will Apache accept ZLIB into the Apache source tree in either
>  >source or binary library format for all platforms.
>  >
>  >Check one box only...
>  >
>  >[__] Yes
>  >[__] No
>  > 
>  
>  Actually, it's not a binary answer... Since Yes implies that the
>  ASF would accept binary library, which ain't the case, and No implies
>  that we wouldn't accept source, which may not be

Yea... I guess the minute I hit send I realized that 'if' statement
was missing some 'else'. ROFL

How about this...

Will the Apache group accept the ZLIB source code
into the distribution tree at this time?...

[__] Yes
[__] No

if ( Yes )
  {
1. Where will it be? /srclib/zlib?
2. Who is going to add it and when?
  }
else
  {
Will Apache accept pre-compiled ZLIB libraries into the
 source tree ( for any/all platforms )?

[__] Yes
[__] No

if ( Yes )
  {
1. Where will the ZLIB libraries be? /srclib/?  /support/zlib?
 
2. Who is going to add them and when?
  }  
else
  {
1. How can anyone vote on adding Ian's mod_gz to the source tree
when the public domain libraries it needs can't be in the source 
tree?
2. How is anything in Apache that ever needs ZLIB supposed to  
compile? Users must always 'go and get' the libs themselves?
  }

  }/* End 'else' */

>  zlib is a very large chunk of code, 

Not really... but I guess some might think so.

ASIDE: You really only need the 'compression' part of it. You
are a Server, not a client.

> and we resist requiring external
> code unless:
>  
>1. It's small
>2. It's very stable (ie: don't have to keep updating it all the
>   time, nor worry about passing patches back).
>3. It's used by a large chunk of the Apache code (eg: regex).

>  Does zlib fit the bill?? Well, not for #1 and not really for #3...

Numbers 1 and 2 already sound like the compressor that's
in mod_gzip and is NOT ZLIB ( minus all the debug code, of course ).
It's VERY stable and VERY small ( 20k or so ).

As for number 3... I am still of the opinion that your perspective
is wrong... you are playing 'chicken or egg'. I am of the opinion
that if ZLIB WAS there then in very short order there WOULD 
be a 'large chunk of Apache code' that uses it. This is ( and I guess
always has been ) my point.

'Build it and they will come...'
'Include the libs and they will be used ( a lot )...'

Something like that

How in the heck tod the REGEX stuff ever make it in?
Was that some huge 'catch 22' or 'chicken and egg' scenario
as well when it was being proposed?

What was the final straw that broke the stalemate over the
'regexec' library inclusion(s)?

>  Does that mean we'd never consider it... I'm not willing to say so.

Then it's happening all over again.

Everyone has an opinion but no one will VOTE one
way or the other.

What's it going to take to find out once and for all if
ZLIB can be included in the Apache source tree?

I don't know anymore. I've tried to explain why I think
it would be a great benefit to Apache to have it there
( numerous times going back over a year or more )
and I have tried to supply as much information as I
have about the licensing issues ( IANAL ) and I
have asked for 'real' votes about it... nothing happens...
just more talk.

Somebody else needs to take this into the end-zone.
I don't even know where the football is on this one
anymore.

Yours...
Kevin Kiley

Re: [PATCH] Add mod_gz to httpd-2.0

[Günter Knauf]

Hi Kevin,

> Guenter Knauf wrote...

>> Hi,
>> I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32
>> and it works for me.
> What did you test?
that it compiles, loads into server and compresses.
> How 'heavily loaded' was the Server?
you're right, I did only a quick test with some huge text pages; and I didnt compare 
against your mod_gzip; but real comparing isnt possible yet because then I have to 
compare also Apache 1.3 with 2.0: I dont have your 2.0 gzip module.

> Did you just ask for 1 thing, see if it came back compressed, and you
> are calling that 'success'?
see above: I cannot compare against what I dont have.
> There's a LOT more to it than that.
maybe; and after I've read your long letter I see some things clearer...

>> And even if a module compiles without changes and no
>> porting is needed it's not guaranteed to run.
>> The best sample is mod_gzip: I use it on Linux and Win32, but on
>> NetWare the module compiles fine but doesnt work!
first of all you see I use your module and I know of the benefits of saving bandwidth 
or else I woudnt try to get it on all platforms.

> This was/is an Apache 1.3.x issue only and this issue
> was resolved on the mod_gzip forum. mod_gzip forum users have been
> VERY good at helping each other out. mod_gzip for Apache 1.3.x doesn't
> work 'out of the box' for IBM's rewrite of Apache, either, and in both
> cases it's because those vendors are re-writing Apache headers and making
> changes that are not in the standard Apache distributions ( or even
> available anywhere online ).
That's not true! I have downloaded your complete 12MB archive and searched for 
'netware': not one thread dealing with NetWare, so please direct me to the message 
where the issue is solved!!
I found 'netware' a couple of times and it was always a #ifdef line from a patch for 
getting POST to work. I found nothing related to the general failure of mod_gzip on 
NetWare! Also you can see in your archive what happens to other platforms which are 
not delivered with a complete C/C++ development as Unix/Linux: they try to compile 
with Borland and many other things...
That's my mainly reason why I want to see a gzip module in the Apache sources: then it 
will be build for all platforms and distributed with the binaries. 
With all non *nix platforms you had to buy very expensive compilers; only since a 
short time we're now able to compile with gcc for Win32 (CygWin) and NetWare 
(gcc/nlmconv)...

> That being said... if I recall a number of the Netware problem
> reports were simply from people that didn't realize you CAN use
I wonder who should this be? I know only one other who compiles for NetWare self...
and again please show me this reports, in the 12 MB mail archive is nothing!

> mod_gzip to compress your SSL output but it takes a special
> configuration. People were reporting output lengths of ZERO
> in the compression statistics in ACCESS_LOG and didn't realize
> that what happens is that SSL 'steals away' the connection handles
> under Apache 1.3.x and delivers the responses outside of the
> normal Apache delivery process. The pages were being delivered
> fine but without the special configuration for mod_gzip they
> were simply not being compressed.
Well Kevin, if you believe I'm too stupid to check if I have loaded SSL, TLS or 
something like that, then we stop discussion here. I told you more than one time that 
I DONT USE SSL nor TLS nor ANY OTHER MODULE AS THE STANDARD COMPILED IN ONES!!!

Also I dont know why you discontinued in helping me find the bug (whereever it sits). 
I was glad that you immediatly replied a few times and it seemed to me that you were 
interested in supporting a new platform. Last thing was that I sent you a debug file 
created from mod_gzip, and I hoped that you could point me to something ot give some 
hints because you know exactly what your code should do, but then nothing came back...

Again: I'm interested in getting mod_gzip working on NetWare with Apache 1.3, I'm able 
to compile your module as well as the whole server, I have a testmachine and when you 
give me patches, hints, tips or whatever you have I will test it and let you know the 
results.

> There are 'patches' available for mod_gzip that solve the Netware
> and IBM HTTPD issues. I believe Bill Stoddard himself is currently
please point me to this patch or send it to me and I will immediatly check it...

> I don't personally have/use Netware ( or IBM's HTTPD ) but other users on
> the mod_gzip forum worked this out for themselves, as any good forum group
> will do.
again: please point me to this patch or send it to me and I will immediatly check it...

please notice that I like your module and still interested in getting it working on 
NetWare...

Thanks, Guenter.

Re: [PATCH] Add mod_gz to httpd-2.0

[Eli Marmor]

Jim Jagielski wrote:
> 
> At 8:42 AM +0200 9/4/01, Eli Marmor wrote:
> >
> >Then, the command "size mod_gzip.o" will be invoked, and its output, which
> >is based only on the REAL code (without the 90% debugging stuff, comments,
> >etc.) will be the base for a decision.
> >
> 
> Certainly not the *sole* basis for a decision... :)

This was only an answer for anybody who was worried of the size.

In my message, I menioned the other issues (i.e. independency on zlib,
etc.).

-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel

Re: [PATCH] Add mod_gz to httpd-2.0

[Jim Jagielski]

At 9:53 PM -0400 9/3/01, [EMAIL PROTECTED] wrote:
>
>That's right and one of them is...
>
>Will Apache accept ZLIB into the Apache source tree in either
>source or binary library format for all platforms.
>
>Check one box only...
>
>[__] Yes
>[__] No
> 

Actually, it's not a binary answer... Since Yes implies that the
ASF would accept binary library, which ain't the case, and No implies
that we wouldn't accept source, which may not be

zlib is a very large chunk of code, and we resist requiring external
code unless:

  1. It's small
  2. It's very stable (ie: don't have to keep updating it all the
 time, nor worry about passing patches back).
  3. It's used by a large chunk of the Apache code (eg: regex).

Does zlib fit the bill?? Well, not for #1 and not really for #3...
Does that mean we'd never consider it... I'm not willing to say so.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: [PATCH] Add mod_gz to httpd-2.0

[Jim Jagielski]

At 8:42 AM +0200 9/4/01, Eli Marmor wrote:
>
>Then, the command "size mod_gzip.o" will be invoked, and its output, which
>is based only on the REAL code (without the 90% debugging stuff, comments,
>etc.) will be the base for a decision.
>

Certainly not the *sole* basis for a decision... :)
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

Hi Eli...
Kevin Kiley here..

In a message dated 01-09-04 03:54:15 EDT, Eli Marmor writes...

> Ian Holsman wrote:
>  
>  > 4. mod_gzip is beter
>  > It could be, and it probably does a better job of compression. 
>  > Once your code is published we'll see. If it is better it will 
replace 'gz'
>  > (if gz gets accepted) my only issue with mod_gzip (1.3 not 2) is 
it's
>  > size, and it's replication of what looks like gzip code inside 
of it.

Couple of points here...

1. mod_gzip is ALREADY 'published'. It has been freely available for just
about one year now and except for a few early bug reports and the addition
of user-requested features it has worked fine since DAY ONE. I don't know why 
everyone keeps acting like a 2.0 version of a module is so significantly 
'different' 
from a 1.3.x module that you have to 'see it to believe it'. I can tell you 
right now
that converting from 1.3.x to 2.0 ( once the filtering API's were finally
stablized ) was simply no big deal and I most certainly did not 'rewrite'
the thing from scratch just because BUFF.C went away. Just look at any 
I/O section of any module and it doesn't take much imagination to visualize 
what it's going to look like with 2.0 filtering calls added.

2. The 'size' issue has been beat to death. Look at the code. As someone
already reported... about 90 percent of it doesn't even need to be there.
It's simply 'storytelling' debug style. Like SQUID Proxy Cache debug on 
steroids.

3. Any implementation of  patent-free LZ77 + Huffman is going to 'look' like
the code known as 'deflate', GZIP and/or ZLIB... because that's what they are.
All Mark and Jean did years ago was rewind to (inferior but free) versions of 
LZ and 
Huffman when Sperry Rand and IBM patented LZW and locked it up for themselves.
Anyone can do it (well, maybe not anyone) and you don't need GZIP or ZLIB.

>  Since I don't see that this discussion is going to anywhere, let me suggest
>  the following, in order to have a progress:
>  
>  Kevin will publish his code for 2.0, although he prefers to wait for a more
>  stable release of 2.0.
>  
>  "In return", nobody will judge it according to its current status, since
>  Kevin already proved (in the 1.3's release) that he could write a high
>  quality mod_gzip, so the assumption will be that if it happened with 1.3,
>  it will happen with 2.0 too, once 2.0 will meet Kevin's standards. In
>  addition, Kevin has more experience in this field than anybody else.

Geesus... it sounds like we are arranging a prisoner exchange on 
some bridge that crosses the Rhine.

More points here...

No, Kevin does NOT have more experience in this field 'than anyone else'.

WE ( as a company )  just happen to have a lot of it. We have been compressing
Internet traffic even before RFC2016 and since the first time we pressed 
'View Source'
on an HTML page and saw all that bloated crap that was arriving over a TCP/IP
connection. We had ( and still have ) client-side software that made ANY 
TCP/IP
installation able to receive compressed data regardless of whether some dumb
browser can or not. IETF Content-Encoding is only one way to do it and if it's
available, we use... that's all. It's just something we do and it's certainly 
not the 
only thing we do.

Also... 'Kevin' does not have any complicated 'standards' for Apache 2.0.
I just want the people that WROTE it to say they believe in it enough to
take it out of skunk-works status and that they TRUST it enough to let 
real people use it. That's not a lot to ask for something that's been worked 
on
for YEARS now. Just get it out the damn door.

( I am SURE I am not alone on this point )

>  The "size" problem will be judged simply:
>  
>  Once the code is published, it will be compiled under a standard platform
>  (Linux?), and with the default flags (i.e. no "-g" or "-DMOD_GZIP_DEBUG1").
>  
>  Then, the command "size mod_gzip.o" will be invoked, and its output, which
>  is based only on the REAL code (without the 90% debugging stuff, comments,
>  etc.) will be the base for a decision.

Huh?
Not sure I followed that one.

I actually had no intention of submitting anything that has any SQUID style
'storytelling' debug in it because history has proven that most of the Apache
folks just can't deal with it... they always bitch about it and/or use it as 
a 
reason to reject something. 'Too much to read' or 'Too hard to read' or 
'Please submit smaller files' or something like that.
  
>  I suggest also to take into account that this code contains EVERYTHING (I
>  believe that zlib alone is bigger than it), so you don't need anything else
>  or any dependency.

I have already gone over the 'licensing' issues as I understand them with
regards to Apache's fears about including other public domain source code
into Apache and the possibility of one day being held to the 'least 
restrictive
OpenSource license in a codebase shall apply to the work as a whole' issue.

That alone migh

Re: [PATCH] Add mod_gz to httpd-2.0

[Eli Marmor]

Ian Holsman wrote:

> 4. mod_gzip is beter
> It could be, and it probably does a better job of compression. Once
> your code is published we'll see. If it is better it will replace 'gz'
> (if gz gets accepted) my only issue with mod_gzip (1.3 not 2) is it's
> size, and it's replication of what looks like gzip code inside of it.

Since I don't see that this discussion is going to anywhere, let me suggest
the following, in order to have a progress:

Kevin will publish his code for 2.0, although he prefers to wait for a more
stable release of 2.0.

"In return", nobody will judge it according to its current status, since
Kevin already proved (in the 1.3's release) that he could write a high
quality mod_gzip, so the assumption will be that if it happened with 1.3,
it will happen with 2.0 too, once 2.0 will meet Kevin's standards. In
addition, Kevin has more experience in this field than anybody else.

The "size" problem will be judged simply:

Once the code is published, it will be compiled under a standard platform
(Linux?), and with the default flags (i.e. no "-g" or "-DMOD_GZIP_DEBUG1").

Then, the command "size mod_gzip.o" will be invoked, and its output, which
is based only on the REAL code (without the 90% debugging stuff, comments,
etc.) will be the base for a decision.

I suggest also to take into account that this code contains EVERYTHING (I
believe that zlib alone is bigger than it), so you don't need anything else
or any dependency.

Also, the fact that much of its size is dedicated for meeting the RFC, must
be taken into account. Once another gzip filter meets it, it will become
large too.

I apologize in advance if I offence anybody; I'm just trying to settle the
argument and to make some progress; I believe that finally there is a 
concensus that having a gzipping filter is critical for the success of
Apache. I hope we will not be back with sayings like "let PHP and JSP
compress themselves"; It is not acceptable, and it's like saying "let PHP
and JSP SSLing themselves". Didn't we invite the I/O filtering for these
purposes?

Sorry again,
-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-03 19:12:38 EDT, Marc slemko wrote...

> > Marc,
>  > 
>  > Rather than continue this thread let's see if we can put this subject
>  > into the end zone.
>  
>  There are numerous unresolved issues and unanswered questions that
>  have been brought up.  The only way to get anywhere is to change them
>  from unresolved to resolved and unanswered to answered and go from there.

That's right and one of them is...

Will Apache accept ZLIB into the Apache source tree in either
source or binary library format for all platforms.

Check one box only...

[__] Yes
[__] No
  
>  > >> Think then act, not the other way around.
>  > 
>  > Then vote on it. Either +1 or -1 on including mod_gzip into the Apache
>  > distribution.
>  
>  "thinking" == discussing the issues and coming to a conclusion
>  "acting" == voting based on that conclusion and then implementing
>  the results of the vote
>  
>  Note again: think _then_ act.
>  
>  There isn't even any code to vote on.

Yes, there is... Ian's mod_gz.
  
>  > 
>  > Simple.
>  
>  Ok, so what you are saying by not wanting to continue discussion
>  on the issues raised or to answer the questions presented to you
>  is that you aren't interested in working with us to contribute a
>  2.0 mod_gzip to Apache.  

Horseshit. Read the thread.

> That is, of course, a decision that you
> are free to make.  But make sure you understand that it is _you_
>  deciding this, not anyone else.

That's right... it's OUR decision.

If we have decided to wait until the Server doesn't have as many
problems as it does right now before we get entangled in this
2.0 mess along with you... and that decision prevents a wildly
successful and useful codebase from becoming part of the
Apache distribution even at some future date... then so be it
( and you can kiss my ass ).

Go ahead and add Ian's weekend-warrior filtering demo RIGHT NOW
and start hacking on it to make it real. Good luck to you.

That's just what Apache needs right now... another half-baked
half-finished module sitting in the source tree.

>  Alright then, end of thread.

Don't bet on it.

Yours...
Kevin Kiley

Re: [PATCH] Add mod_gz to httpd-2.0

[Ian Holsman]

[EMAIL PROTECTED] wrote:

> Hello all...
> Kevin Kiley here...


hi Kevin.
I'm finding that your comments
are getting to be a bit of flamebait,
I'll try not to respond in kind.

1. weekend warrior.
I am currently the tech lead of apache 2
development over here at CNET. I'm doing this
full time.
We are currently working on faster versions of
rewrite (a smaller subset of functionality), setenv_if,
mod_include, and some internal proprietry modules.

The GZ filter was written over a weekend due to
2 reasons. It just does GZip, no caching, fancy
logging or other stuff handled by the core. It uses
existing code libraries (APR/ZLIB) instead of re-inventing
the wheel.

2. Support
your right, I do not want to be the maintainer of 'gz'
thanks to it useing exising libraries and it size (~400 lines)
I don't have to be. already 2 people have reviewed/patched it.
the code is simple and IMHO easy to understand.

3. it is a demo
The code is only a demo because I haven't had the time to test it
fully. If the CPU usage of mod_include goes down enough it will be
tested ~800 times a second on our main servers. Otherwise it will
be relegated to our low traffic sites. The code will go through
full QA/Performance testing, and patches will be submitted back to
Apache

4. mod_gzip is beter
It could be, and it probably does a better job of compression. Once
your code is published we'll see. If it is better it will replace 'gz'
(if gz gets accepted) my only issue with mod_gzip (1.3 not 2) is it's
size, and it's replication of what looks like gzip code inside of it.

nuff said,

hopefully a GZ filter will get included into the core.
Ian

> 
> Here is a mixture of comment/response regarding mod_gzip and the
> ongoing conversation(s)...
> 
> There is a (short) SUMMARY at the bottom.
> 
> Justin ErenKrantz's original post...
> 
> 
>>Ian has posted his mod_gz filter before, now I'd like to give it a +1.
>>
>>I told him I'd look at it a while ago, but never got a chance to do 
>>so.  So, I spent this morning cleaning up the configuration and a bit 
>>of the code to fit our style (nothing major).
>>
>>I'd like to add this to the modules/filters directory (which seems
>>like the most appropriate place).
>>
>>Justin
>>
> 
> Ryan Bloom responded...
> 
> 
>>I have a few problems with this.  1)  We have consistantly declined to
>>accept the mod_Gzip from remote communications.  
>>
> 
> Correct... and for a while the reason was because everyone thought the
> module was using ZLIB and there has been a long standing aversion to
> including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
> Apache tree. We have personal emails from your board members stating
> that to be the case. If that aversion has evaporated then there is a TON of
> GNU based stuff that is now 'eligible' for inclusion in the core
> distribution, right?
> 
> GNU issues aside... we have consistently been told that the other reason
> mod_gzip would not be included is because of the 'support' issue. Apache
> has a standing rule that no module goes into the distribution unless you
> are absolutely SURE that it will be adequately supported. Makes sense.
> 
> We have been consistently supporting this technology for years now.
> Ian himself said he 'Just got bored and decided not to do any real
> work one weekend' and cranked out a filter demo that happened to
> include ZLIB. He has not demonstrated any intention of actually
> 'supporting' it other than making a few modifications to the 'demo'
> ( and even those have yet to appear ).
> 
> If that doesn't raise the issue of 'will it be supported' I don't
> know what would.
> 
> mod_gzip has NEVER used 'ZLIB' for a number of reasons... the primary
> one being that ZLIB is inadequate for the purpose. ZLIB is a 
> non-multithread-safe
> file based compression library. The secondary reason is actually so 
> that you folks wouldn't have to worry about the 'GNU' issues you have if/when
> you wanted to use the code. Read the comments at the top of mod_gzip.c
> right underneath the Apache license section which has always been at
> the top of mod_gzip and the syntax of which was personally approved
> by at least 3 of your top level board members via personal email(s).
> 
> 
>>2) I keep hearing that zlib has more memory leaks than a sieve.  
>>
> 
> It does. Any non-multithread-safe file oriented library does if you
> just slap it into a multithread environment and start using it without
> putting critsecs around the calls to serialize it.
> 
> 
>>3)  I don't believe that we
>>should be adding every possible module to the core distribution.  
>>
> 
> That's always been the rule. It is still a mystery when/how something
> 'rises' to the level of importance to be included in the Apache
> distribution ( E.g. WebDav, etc ). That being said..

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-03 21:11:29 EDT, you write:

> On Monday 03 September 2001 17:24, Graham Leggett wrote:
>  > Justin Erenkrantz wrote:
>  > > (I need to double check that mod_gz and mod_include don't interfere
>  > > with each other...mod_gz should run *after* mod_include has processed
>  > > the data...)
>  >
>  > mod_gzip is a transfer encoding, mod_include is a content filter.

Nope.

Content-encoding: gzip

To this day no browser I know of can successfully receive
Transfer-encoding: gzip
much less
Transfer-encoding: gzip, chunked.

The latter will cause the blue screen of death in MSIE and
will also cause every one of the top ten selling HTTP 
benchmarking suites to puke.

Until America Online (Netscape) or Microsoft get off their asses
and add full HTTP/1.1 support to ANY version of their browsers 
the only hope of delivering compressed responses is...

Content-encoding: gzip

Yours...
Kevin Kiley.

>  > Perhaps we need a clear distinction within filters between transfer
>  > encoding modules and content modules.
>  
>  We have always had that distinction.
>  
>  Ryan

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

On Monday 03 September 2001 17:24, Graham Leggett wrote:
> Justin Erenkrantz wrote:
> > (I need to double check that mod_gz and mod_include don't interfere
> > with each other...mod_gz should run *after* mod_include has processed
> > the data...)
>
> mod_gzip is a transfer encoding, mod_include is a content filter.
>
> Perhaps we need a clear distinction within filters between transfer
> encoding modules and content modules.

We have always had that distinction.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

On Monday 03 September 2001 11:36, William A. Rowe, Jr. wrote:
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Monday, September 03, 2001 12:57 PM
>
> > I also think that we do not need to redistribute zlib in our source
> > tree.  I think it is common enough now that most OSes come with it.
> > (I look at how we handle the OpenSSL library and think zlib falls
> > in the same category.)
>
> We don't distribute OpenSSL because it's a huge chunk of code!!!
>
> We certainly can't rely on folks having 0.9.6b installed (or even 0.9.6a,
> the absolute minimum to avoid some pretty significant holes, leaving a
> problem or to remaining.)  But we aren't about to distribute that much
> code, we have a relationship with the maintainers (one sits on the ASF
> board), and _new_ crypto development still has hardships within the US. 
> There is nothing new or novel about mod_ssl, which is why we have no
> problem falling under the crypt export relaxation for 'publicly available
> open sources'.
>
> I have no issue with dropping the current (and httpd-maintained) zlib,
> returning all patches to the authors.  If there are problems with threading
> support + leaks, we will need to fix them if we will call this 'supported'.
>  Same as we do for pcre and expat, which aren't as firmly established as
> the ASF or even the OpenSSL organization.  It adds some 160kb to the
> tarball, as distributed at zlib.org.

I have a big problem with this.  We had a hard enough time contributing
patches back to MM.  The only reason we keep expat and pcre up to date,
is that we NEVER make any changes to them.  I would be very much against
adding zlib to our tree.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[Graham Leggett]

Justin Erenkrantz wrote:

> (I need to double check that mod_gz and mod_include don't interfere
> with each other...mod_gz should run *after* mod_include has processed
> the data...)

mod_gzip is a transfer encoding, mod_include is a content filter.

Perhaps we need a clear distinction within filters between transfer
encoding modules and content modules.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."
 S/MIME Cryptographic Signature

Re: [PATCH] Add mod_gz to httpd-2.0

[Graham Leggett]

Ryan Bloom wrote:

> You know what's really funny?  Every time this has been brought up before,
> the Apache core has always said, if you want to have gzip'ed data, then
> gzip it when you create the site.  That way, your computer doesn't have to
> waste cycles while it is trying hard to serve requests.  I personally stand by
> that statement.  If you want to use gzip, then zip your data before putting it
> on-line.  That doesn't help generated pages, but perl can already do gzip, as
> can PHP.

Neither mod_perl nor mod_php should have to do gzip, as it's a transfer
encoding - it should be done transparently.

The job of making mod_gzip efficient (AKA not gzipping every file on
every request) is the job of mod_cache with cache_storage.c
optimisation. mod_gzip should be applied to all output where possible,
not just static files.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."
 S/MIME Cryptographic Signature

Re: [PATCH] Add mod_gz to httpd-2.0

[Ian Holsman]

Justin Erenkrantz wrote:

> On Sun, Sep 02, 2001 at 12:43:09PM -0500, William A. Rowe, Jr. wrote:
> 
>>>The gzip content encoding is part of the HTTP spec. 
>>>
>>By implementation, or reference?  Sure Content-encoding is part of the spec, and
>>it's defined to allow authors to extend their support to any number of encodings,
>>and forces the server to use only what the client claims as supported encodings.
>>
> 
> gzip is mentioned explicitly in RFC 2616 as a supported content-encoding
> (one registered with IANA).
> 
> 
>>+1 with caviat to follow.
>>
> 
> Cool.  BTW, do these +1 (concept) votes count towards mod_gz's 
> inclusion?  I now count three binding +1 (concepts) for this (Cliff,
> Greg, and OtherBill).  Or, do I need to wait until I receive two
> +1s for mod_gz explicitly?
> 
> 
>>So we need any gzip filter to drop out quick if 1. it knows this mime type should
>>not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the
>>uri/filename whatever in a list of exclusions (that could be automagically grown
>>when it hits files that _just_don't_compress_well_.
>>
> 
> I would think that this is a httpd.conf configuration issue.  Remember,
> we add mod_gz via:
> 
> AddOutputFilter GZ html
> 
> Ian's version did make sure that the content-type was text/html before
> encoding.  But, I don't think that is necessary.  If the admin sets
> mod_gz via the OutputFilter semantics, that's their wish (remember,
> you must *ask* for mod_gz).  I'd rather not see these types of 
> assumptions in any gzip module we implement.


It should only compress html files.
the main reason for this is that some browsers (IE) can't handle compressed
Javascript and CSS files (that what the mod_gzip discussion boards say)


> 
> (I need to double check that mod_gz and mod_include don't interfere
> with each other...mod_gz should run *after* mod_include has processed
> the data...)
> 

it does. GZ is a AP_FTYPE_HTTP_HEADER filter. mod_include is a content filter.
there is also a check to make sure that it is a 'main' request.



> 
>>If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/
>>instead of by reference.  It really isn't that large, and matches what we do today
>>with pcre and expat.  If we like, drop it into apr-util/encoding/unix/lib/zlib and
>>only expose it through thunks (allowing someone to come up with more robust or faster
>>apr-util thunks to source that we can _not_ redestribute.)  The more I contemplate,
>>the stronger my +1 for apr-util remapping, where appropriate on some platforms.
>>
> 

zlib (and berkley DB for that matter) provide functions for malloc/free
I looked at using pools, but I couldn't see how to pass the pool in.
so that zlib would be able to pass the right pool through.

if someone has some good ideas I'll patch the berkley DB to do that as well.



> Almost every platform I am aware of includes zlib by default now.
> Solaris, AIX, Linux, FreeBSD.  Ian has all of the MSVC files (I didn't
> post them as I want to place it in modules/filters which is different
> than where Ian originally had it) - so I know he has something working
> on Win32.  So, I don't think that we need to distribute zlib.  Nor do 
> we need to perform "thunking."  It's just so common now.

agreed
zlib is everywhere. we should treat it similiar to how openssl libraries
are treated. (for MSVC .. assume they are in srclib/, otherwise --with-z=)


> 
> AIUI, zlibc is completely transparent to any application.  -- justin
> 


..Ian

RE: [PATCH] Add mod_gz to httpd-2.0

[Marc Slemko]

On Mon, 3 Sep 2001, Peter J. Cranstone wrote:

> Marc,
> 
> Rather than continue this thread let's see if we can put this subject
> into the end zone.

There are numerous unresolved issues and unanswered questions that
have been brought up.  The only way to get anywhere is to change them
from unresolved to resolved and unanswered to answered and go from there.

> >> Think then act, not the other way around.
> 
> Then vote on it. Either +1 or -1 on including mod_gzip into the Apache
> distribution.

"thinking" == discussing the issues and coming to a conclusion
"acting" == voting based on that conclusion and then implementing
the results of the vote

Note again: think _then_ act.

There isn't even any code to vote on.

> 
> Simple.

Ok, so what you are saying by not wanting to continue discussion
on the issues raised or to answer the questions presented to you
is that you aren't interested in working with us to contribute a
2.0 mod_gzip to Apache.  That is, of course, a decision that you
are free to make.  But make sure you understand that it is _you_
deciding this, not anyone else.

Alright then, end of thread.

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

Guys,

Whatever you want to do. I don't care. Vote on mod_gz for 2.x and
mod_gzip for 1.3.x (we submitted this to the ASF last October 13 2000)

It's really that simple, you can debate it for evermore. Kevin and I are
focused on mod_gzip 2.x which will be released when 2.x goes solid beta.

This is my last 2 cents worth. Time's a wasting.


Peter

-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]] 
Sent: Monday, September 03, 2001 2:32 PM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Add mod_gz to httpd-2.0


> 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.

It isn't as simple as that.  You can't just call out a vote to push this
through.  Lets let this issue settle down first and focus on 2.0 getting
good enough for beta.  In the mean time mod_gz and mod_gzip (if code is
posted) can be reviewed.  If there is a maintainer within the ASF, there
can be a vote if needed.  Otherwise, we don't need a vote, since if the
ASF isn't going to maintain it, it isn't going in *. This is what Marc
was trying to say aswell I think.  I don't think the majority of the
httpd developers are going to +1 putting mod_gzip in.  Remember that
they are the ones having to maintain it and ensure its quality, not you
(unless ofcourse you join the development team).

Right now it seems like some people are getting worked up and that is
not a good environment to make decisions in.  Personally I don't even
think it is time for this decision.

Sander

*) At least that is how I understand it and would find it logical to
   be.

> 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)

Things are getting twisted...

RE: [PATCH] Add mod_gz to httpd-2.0

[Sander Striker]

> 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.

It isn't as simple as that.  You can't just call out a vote to push
this through.  Lets let this issue settle down first and focus on
2.0 getting good enough for beta.  In the mean time mod_gz and mod_gzip
(if code is posted) can be reviewed.  If there is a maintainer within
the ASF, there can be a vote if needed.  Otherwise, we don't need a
vote, since if the ASF isn't going to maintain it, it isn't going in *.
This is what Marc was trying to say aswell I think.  I don't think
the majority of the httpd developers are going to +1 putting mod_gzip
in.  Remember that they are the ones having to maintain it and ensure
its quality, not you (unless ofcourse you join the development team).

Right now it seems like some people are getting worked up and that is
not a good environment to make decisions in.  Personally I don't even
think it is time for this decision.

Sander

*) At least that is how I understand it and would find it logical to
   be.

> 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)

Things are getting twisted...

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Mon, Sep 03, 2001 at 02:16:44PM -0600, Peter J. Cranstone wrote:
> 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.

You haven't submitted a version of mod_gzip for review.  Therefore,
there is nothing to vote on at this time w.r.t. mod_gzip.  

Ian's mod_gz *has* been submitted for review.  That was what my 
initial vote called for a review on.  

If you or Kevin wish to submit a version for potential submission
into httpd-2.0, I would strongly suggest submitting it sooner
rather than later.  -- justin

Re: [PATCH] Add mod_gz to httpd-2.0

[Brian Pane]

Peter J. Cranstone wrote:

>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.
>
That would be tricky, as (to the best of my knowledge) nobody has yet
posted the 2.0 mod_gzip code.

mod_gz looks reasonable, though (both the mod_gz code itself and the 
licensing
and thread-safety of zlib).

--Brian

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

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, Ap

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Mon, Sep 03, 2001 at 01:37:38PM -0600, Jerry Baker wrote:
> Of course, if it's made as easy as dropping the zlib dist into /srclib
> (like OpenSSL), then it doesn't matter to me.

Oh, I see Makefile.win now.  Yes, the Unix build doesn't do that, but 
for Win32, I bet this is a reasonable solution.  If we need to replace
zlib, we just check our zlib into srclib.  Works for me.  -- justin

Re: [PATCH] Add mod_gz to httpd-2.0

[Thomas Eibner]

On Mon, Sep 03, 2001 at 01:37:38PM -0600, Jerry Baker wrote:
> Thomas Eibner wrote:
> > 
> > On Mon, Sep 03, 2001 at 12:22:33PM -0700, Justin Erenkrantz wrote:
> > > My point is that almost every OS comes with a copy of zlib now.  We
> > > can't expect most people to have pcre and expat, but I think we can
> > > with zlib though.  I'd rather not build zlib if we didn't need to.
> > > The exception here is probably Win32 (which is why I think you want
> > > the source).  -- justin
> > 
> > How many people compile Apache on Win32 themselves anyway?
> 
> Me! :-)
> 
> Of course, if it's made as easy as dropping the zlib dist into /srclib
> (like OpenSSL), then it doesn't matter to me.

Okay, right after hitting send I realized that probably a few people do
this as most people want their own setup .. But again, if it's an easy
thing to do then it shouldn't cause to many problems.

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: [PATCH] Add mod_gz to httpd-2.0

[Jerry Baker]

Thomas Eibner wrote:
> 
> On Mon, Sep 03, 2001 at 12:22:33PM -0700, Justin Erenkrantz wrote:
> > My point is that almost every OS comes with a copy of zlib now.  We
> > can't expect most people to have pcre and expat, but I think we can
> > with zlib though.  I'd rather not build zlib if we didn't need to.
> > The exception here is probably Win32 (which is why I think you want
> > the source).  -- justin
> 
> How many people compile Apache on Win32 themselves anyway?

Me! :-)

Of course, if it's made as easy as dropping the zlib dist into /srclib
(like OpenSSL), then it doesn't matter to me.

Re: [PATCH] Add mod_gz to httpd-2.0

[Thomas Eibner]

On Mon, Sep 03, 2001 at 12:22:33PM -0700, Justin Erenkrantz wrote:
> My point is that almost every OS comes with a copy of zlib now.  We
> can't expect most people to have pcre and expat, but I think we can 
> with zlib though.  I'd rather not build zlib if we didn't need to.  
> The exception here is probably Win32 (which is why I think you want 
> the source).  -- justin

How many people compile Apache on Win32 themselves anyway? It should be
enough if the person that creates the Apache Win32 binary has zlib 
installed right? So it really shouldn't be that big of a problem?
Of course the sources could be bundled with a guide on how to install
zlib on Win32 if you really wanted it anyway..

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Mon, Sep 03, 2001 at 01:36:18PM -0500, William A. Rowe, Jr. wrote:
> I have no issue with dropping the current (and httpd-maintained) zlib, returning
> all patches to the authors.  If there are problems with threading support + leaks,
> we will need to fix them if we will call this 'supported'.  Same as we do for
> pcre and expat, which aren't as firmly established as the ASF or even the OpenSSL
> organization.  It adds some 160kb to the tarball, as distributed at zlib.org.

How about we drop in code that uses zlib first and see if there are
really problems with zlib?  If there are, attempt to create patches to 
send to the authors.  Then, if they don't care to address them, we 
check in and create our own zlib with our patches.

My point is that almost every OS comes with a copy of zlib now.  We
can't expect most people to have pcre and expat, but I think we can 
with zlib though.  I'd rather not build zlib if we didn't need to.  
The exception here is probably Win32 (which is why I think you want 
the source).  -- justin

RE: [PATCH] Add mod_gz to httpd-2.0

[Marc Slemko]

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

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

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. 

>> 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. 

>> 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. 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
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.

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.

Regards


Peter


-Original Message-
From: Marc Slemko [mailto:[EMAIL PROTECTED]] 
Sent: Monday, September 03, 2001 12:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


On Mon, 3 Sep 2001, Justin Erenkrantz wrote:

> On Mon, Sep 03, 2001 at 04:40:15AM -0400, [EMAIL PROTECTED] wrote:
> > I suggest (again) that the entire ZLIB source code package be 
> > IMMEDIATELY added to the Apache source code tree. Like... TOMORROW.

Like, no.  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.

> If you are willing to post a version of mod_gzip for httpd-2.0 to this

> list, I will take the time to review it.  However, I think there is an

> advantage to using zlib in this particular case rather than writing 
> our own compression algorithms.  -- justin

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.

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).

In any case, it makes a whole lot more sense to use a library for
supporting gzip than to stick it all as custom code into any place that
needs it (eg. ab, mod_g*, etc.), even if zlib isn't the library to use.

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 12:57 PM


> I also think that we do not need to redistribute zlib in our source
> tree.  I think it is common enough now that most OSes come with it.
> (I look at how we handle the OpenSSL library and think zlib falls
> in the same category.)

We don't distribute OpenSSL because it's a huge chunk of code!!!

We certainly can't rely on folks having 0.9.6b installed (or even 0.9.6a, the 
absolute minimum to avoid some pretty significant holes, leaving a problem
or to remaining.)  But we aren't about to distribute that much code, we have
a relationship with the maintainers (one sits on the ASF board), and _new_
crypto development still has hardships within the US.  There is nothing new or
novel about mod_ssl, which is why we have no problem falling under the crypt
export relaxation for 'publicly available open sources'.

I have no issue with dropping the current (and httpd-maintained) zlib, returning
all patches to the authors.  If there are problems with threading support + leaks,
we will need to fix them if we will call this 'supported'.  Same as we do for
pcre and expat, which aren't as firmly established as the ASF or even the OpenSSL
organization.  It adds some 160kb to the tarball, as distributed at zlib.org.

Bill

Re: [PATCH] Add mod_gz to httpd-2.0

[Marc Slemko]

On Mon, 3 Sep 2001, Justin Erenkrantz wrote:

> On Mon, Sep 03, 2001 at 04:40:15AM -0400, [EMAIL PROTECTED] wrote:
> > I suggest (again) that the entire ZLIB source code package be IMMEDIATELY
> > added to the Apache source code tree. Like... TOMORROW.

Like, no.  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.

> If you are willing to post a version of mod_gzip for httpd-2.0 to
> this list, I will take the time to review it.  However, I think 
> there is an advantage to using zlib in this particular case rather 
> than writing our own compression algorithms.  -- justin

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.

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).

In any case, it makes a whole lot more sense to use a library for
supporting gzip than to stick it all as custom code into any place that
needs it (eg. ab, mod_g*, etc.), even if zlib isn't the library to use.

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Mon, Sep 03, 2001 at 04:40:15AM -0400, [EMAIL PROTECTED] wrote:
> I suggest (again) that the entire ZLIB source code package be IMMEDIATELY
> added to the Apache source code tree. Like... TOMORROW.
> 
> It seems silly to discuss adding anything like mod_gz ( or our Enhanced
> ApacheBench or any built-in IETF Content-encoding support ) unless it is
> first determined if either the GZIP source code (GPL license) or ZLIB 
> ( ZLIB/LIBPNG license) will ever make it into the Apache source tree.
> 
> Votes, anyone?

My interpretation of the ZLIB license at

http://www.gzip.org/zlib/zlib_license.html

leads me to believe that zlib is compatible with the ASF license.  I
believe OtherBill has already commented on that fact.  I do not think
that there are any patent issues on zlib - AFAIK, that was the point 
of writing zlib in the first place.

I also think that we do not need to redistribute zlib in our source
tree.  I think it is common enough now that most OSes come with it.
(I look at how we handle the OpenSSL library and think zlib falls
in the same category.)

If you are willing to post a version of mod_gzip for httpd-2.0 to
this list, I will take the time to review it.  However, I think 
there is an advantage to using zlib in this particular case rather 
than writing our own compression algorithms.  -- justin

Re: [PATCH] Add mod_gz to httpd-2.0

[Eli Marmor]

Jim Jagielski wrote:

>   2. ZLIB issues:
>  Because mod_gzip uses ZLIB, we also need to concern ourselves of
>  the nature (patent, licensing, etc...) of that as well.

mod_gzip does NOT use zlib.
mod_gz uses zlib.

-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

Jim,

1.  There are no patents on any of the technologies contained within
mod_gzip. Neither Remote Communications, HyperSpace
Communications or either Kevin and I have any patent coverage in
this module.

2.  Kevin has already covered the licensing issue in detail. (see
previous threads)

3.  Mod_gzip was released under the "Apache" style license and you
are free to include it.

>> I see no real blocks to the ASF seriously looking at adding the code.

I agree. We we've worked hard to release and "support" a module which
Apache users will find useful. It's coming up a year now and people are
still downloading it.

If the issue is debug code we can always upload a copy which will be
about 90% smaller but tougher to understand for the new user. You could
use this with Apache distributions and we could carry the full debug
version on our site.

Regards


Peter

-Original Message-
From: Jim Jagielski [mailto:[EMAIL PROTECTED]] 
Sent: Monday, September 03, 2001 9:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Add mod_gz to httpd-2.0


At 12:42 PM -0600 9/2/01, Peter J. Cranstone wrote:
>
>It's an amazing analysis of mod_gzip on HTTP traffic and includes all 
>different browser types. Here is what is amazing, check out the "saved"

>column and the "average" savings for all the different stats... About 
>51%
>
>That's a HUGE benefit to ALL apache users. Why wouldn't you use it?
>

Here are my comments regarding mod_gzip...

  1. Yes, it's incredibly useful and a worthwhile module.
  2. Re: "why wouldn't you use it"?? As an end-user (sys-admin) I can't
 think of any real compelling reasons why not...

But I think the question you meant was "why wouldn't the ASF 'bundle' it
with Apache", and the reasons are:

  1. Patent issues:
 I seem to recall that mod_gzip was somehow patented, and with
 some words to the effect that if it's included with software, then
 the software follows suit. Before the ASF can consider the module,
 we must know *exactly* the patent and licensing aspects of the
code.
  2. ZLIB issues:
 Because mod_gzip uses ZLIB, we also need to concern ourselves of
 the nature (patent, licensing, etc...) of that as well.

If you can assure us of no viral aspects of the code (or any required
code libraries of mod_gzip), no patent issues of any aspects of the code
(or it's supporting libraries) and no other conditions of the code
donation, then I see no real blocks to the ASF seriously looking at
adding the code.

As a side point, we really need to do a better job regarding 3rd party
modules... Of course, we can't include every 3rd party module that comes
down the path, and hopefully module authors realize that. But we do need
to make it easier for people to find them, etc...
-- 

===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

RE: [PATCH] Add mod_gz to httpd-2.0

[Jim Jagielski]

At 12:42 PM -0600 9/2/01, Peter J. Cranstone wrote:
>
>It's an amazing analysis of mod_gzip on HTTP traffic and includes all
>different browser types. Here is what is amazing, check out the "saved"
>column and the "average" savings for all the different stats... About
>51%
>
>That's a HUGE benefit to ALL apache users. Why wouldn't you use it?
>

Here are my comments regarding mod_gzip...

  1. Yes, it's incredibly useful and a worthwhile module.
  2. Re: "why wouldn't you use it"?? As an end-user (sys-admin) I can't
 think of any real compelling reasons why not...

But I think the question you meant was "why wouldn't the ASF 'bundle'
it with Apache", and the reasons are:

  1. Patent issues:
 I seem to recall that mod_gzip was somehow patented, and with
 some words to the effect that if it's included with software, then
 the software follows suit. Before the ASF can consider the module,
 we must know *exactly* the patent and licensing aspects of the code.
  2. ZLIB issues:
 Because mod_gzip uses ZLIB, we also need to concern ourselves of
 the nature (patent, licensing, etc...) of that as well.

If you can assure us of no viral aspects of the code (or any required
code libraries of mod_gzip), no patent issues of any aspects of the
code (or it's supporting libraries) and no other conditions of the
code donation, then I see no real blocks to the ASF seriously looking
at adding the code.

As a side point, we really need to do a better job regarding 3rd party
modules... Of course, we can't include every 3rd party module that
comes down the path, and hopefully module authors realize that. But we
do need to make it easier for people to find them, etc...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

On Monday 03 September 2001 03:32, Gomez Henri wrote:

> You're right, now the gzip code in included in mod_gzip.c
> and didn't rely anymore on the zlib external lib. And I
> didn't even noticed :(
> Question, when did you included the gzip code in mod_gzip ?
> I remember I've to add -lz -lm when compiling in early age of
> mod-gzip


> May be APR team could use you code to make it available to
> others modules or apps :!!!

No.  APR-util has already become too much of a kitchen sink.  There is
no reason to include compression in APR or APR-util.  If you want to have
a compression library, then create a compression library.  Do not try to 
put it into another library.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[Greg Stein]

On Sun, Sep 02, 2001 at 11:42:48AM -0500, William A. Rowe, Jr. wrote:
>...
> WebDAV isn't a 'done' protocol, and really started out as the WebDA protocol

The portion of WebDAV defined by RFC 2518 is *very* done. It kinda has to
be, to be an RFC :-)

> (versioning deferred until we figure out how it should be described.)

mod_dav already supports DeltaV, provided a backend that actually implements
it. There may need to be some tweaks for the recent drafts, but Apache's
support is done. (I doubt mod_dav_fs would *ever* want to natively support
DeltaV; that is definitely for third party backends)

> I'm sure it will grow.

Actually, I would doubt that. It's got all the bits in there already. If
anything, it could shrink over time. Stuff like "If:" header handling is
appropriate to the whole server, not just DAV. And there are some utilities
and other items that are redundant or can be migrated (e.g. time
formatting).

In truth, mod_dav is a (functionally) stable piece of code with a highly
dedicated maintainer. There are ways to improve it, and I'm actually in
process on an improvement currently (it *shrinks* mod_dav, although
mod_dav_fs grows some). It isn't like mod_proxy which used to be buggy and
under-featured, or mod_rewrite without an RFC or a maintainer.

> In a perfect world, apache-2.0.26-gold-core.tar.gz contains just the core.  Then
> give the world apache-2.0.26-gold-all-gold-20010915.tar.gz with all _released_ 
> subprojects effective 2001.09.15 rolled in!  The adventurous could try the
> apache-2.0.26-gold-all-beta-20010915.tar.gz.  Finally, the looney (most folks
> that follow this list) can grab apache-2.0.26-gold-all-alpha-20010915.tar.gz
> for alpha releases of every module (probably a longer list, since some subprojects
> at a given time likely haven't gone gold just yet.)

I don't like your package/version names :-), but I completely agree with the
concept. It's what I advocated when we were discussing what to do about the
proxy stuff (and each time since).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] Add mod_gz to httpd-2.0

[Gomez Henri]

>Hi Henri...
>This is Kevin Kiley.
>It isn't necessary to ask Jean or Mark about leaks in ZLIB with
>regards to mod_gzip or add any 'warnings' because mod_gzip
>does NOT USE ZLIB. 

Hi Kevin, happy to see you there :)))

You're right, now the gzip code in included in mod_gzip.c
and didn't rely anymore on the zlib external lib. And I
didn't even noticed :( 
Question, when did you included the gzip code in mod_gzip ?
I remember I've to add -lz -lm when compiling in early age of
mod-gzip

>There are no 'leaks' of any kind in mod_gzip
>and since it uses its own context-based control deck for all compression
>tasks it is 100% thread-safe.

true...

Your suggestion is a good one but it would only apply to things 
that actually use ZLIB such as Ian's 2.0 filtering demo.
> >And Tomcat 4.x :)
> >Pier

May be APR team could use you code to make it available to
others modules or apps :!!!

Thanks Kevin, I also updated my mod_gzip RPM :

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-03 04:55:08 EDT, Henri Gomez writes...

> >"Ryan Bloom" <[EMAIL PROTECTED]> wrote:
>  >> If you want to use gzip, then zip your data before putting it on-line.
>  That
>  >> doesn't help generated pages, but perl can already do gzip, as can PHP.
>  
>  Let me expose my mod_gzip user experience.
>  
>  I'm using it for more that 9 months on Apache 1.3 servers and never
>  had any problems with it. It's really a great piece of code and all
>  my end users are more than happy to get their stuff quicker.
>  
>  What about asking Jean-loup Gailly and Mark Adler about
>  the leaks in zlib library, and possible fixes ? In case of severe
>  problem, you could still add a warning to mod_gzip potential
>  users.

Hi Henri...
This is Kevin Kiley.

It isn't necessary to ask Jean or Mark about leaks in ZLIB with
regards to mod_gzip or add any 'warnings' because mod_gzip
does NOT USE ZLIB. There are no 'leaks' of any kind in mod_gzip
and since it uses its own context-based control deck for all compression
tasks it is 100% thread-safe.

Your suggestion is a good one but it would only apply to things 
that actually use ZLIB such as Ian's 2.0 filtering demo.
  
>  >And Tomcat 4.x :)
>  >Pier
>  
>  Hello, Pier, happy to see your here also.
>  
>  Compression is a time consuming task and I'd rather like to see it
>  handled by native code instead of  java code.
>  
>  Of course the same thing is true for Crypto operation, and that's why
>  I was more than happy to see mod_ssl contributed to Apache 2.0 :)))

Yours...
Kevin Kiley

Re: [PATCH] Add mod_gz to httpd-2.0

[Gomez Henri]

>"Ryan Bloom" <[EMAIL PROTECTED]> wrote:
>> If you want to use gzip, then zip your data before putting it on-line.
That
>> doesn't help generated pages, but perl can already do gzip, as can PHP.

Let me expose my mod_gzip user experience.

I'm using it for more that 9 months on Apache 1.3 servers and never
had any problems with it. It's really a great piece of code and all
my end users are more than happy to get their stuff quicker.

What about asking Jean-loup Gailly and Mark Adler about
the leaks in zlib library, and possible fixes ? In case of severe
problem, you could still add a warning to mod_gzip potential
users.

>And Tomcat 4.x :)
>Pier

Hello, Pier, happy to see your here also.

Compression is a time consuming task and I'd rather like to see it
handled by native code instead of  java code.

Of course the same thing is true for Crypto operation, and that's why
I was more than happy to see mod_ssl contributed to Apache 2.0 :)))

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

In a message dated 01-09-02 19:34:47 EDT, Cliff Wooley wrote...

> On Sun, 2 Sep 2001 [EMAIL PROTECTED] wrote:
>  
>  > Correct... and for a while the reason was because everyone thought the
>  > module was using ZLIB and there has been a long standing aversion to
>  > including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
>  > Apache tree. We have personal emails from your board members stating
>  > that to be the case. If that aversion has evaporated then there is a TON 
of
>  > GNU based stuff that is now 'eligible' for inclusion in the core
>  > distribution, right?
>  
>  What Brian said.  Are we talking about the same zlib?  The one I know
>  about is the one Brian linked to, which is NOT GPL and hence is eligible.
>  No GPL code is eligible due to the "viral" effect of the GPL on code that
>  uses it.

Cliff... you are right... It was a mistake for me to say that ZLIB is released
under the actual GNU/GPL license... it is not... it is released under the
less restrictive ZLIB/LIBPNG license. It is GZIP itself that is still under
GNU/GPL and since ZLIB is based on GZIP ( and both are based on
the deflate algorithm ) I still get the 2 mixed up.

Whether or not the same algorithm existing in the public domain under
2 different licenses means that the 'least' restrictive or the 'most' 
restrictive
license actually applies under challenge is a matter for lawyers to decide
but in general the law usually says that when 2 disparate licenses cover
the same entity the 'least restrictive' license shall apply.

Speaking of which... I think I should point out that I am in no way opposed
to Apache adding ZLIB to the core distribution and it would just be too
weird for words to be characterized as such.

I was actually the one who submitted source code ( over a year ago ) that 
required ZLIB and I was the one who 'tested the waters' and requested that 
ZLIB be 
added to the Apache source code tree right away not just for the code that 
was submitted 
( patches to ApacheBench which used ZLIB to accept/decode/verify IETF 
Content-Encoding ) but for ANYTHING in the entire Apache package that 
might benefit from ZLIB being available in the tree.

Both the code ( patches to ApacheBench ) and the idea of adding ZLIB 
were rejected.

As we say here in Arkansas 'I have slept since then' so unless I am mistaken
the end result of the firestorm that took place over adding ZLIB to Apache 
was still based on a reluctance to add any code that was not covered by
an actual 'Apache' license to the Apache source code tree.

I believe the objections were ( rightly ) based on the concerns surrounding
the 'least restrictive license' clause that actually casts an invisible pall
over much of Open source coding.

Most people reading/quoting OpenSource and/or GPL/GNU licenses don't really 
understand this clause but lawyers do. What it means is that whenever you 
start 
'mixing' source code that is covered under different licenses there is always 
the 
chance that some legal entity could find ( for a plaintiff ) that the 'least 
restrictive 
license shall apply to the work as a whole'. If someone at Apache is still 
afraid
that in the event the Apache license is ever challenged ( not likely but just 
about
all of this IP based lawering is always based on 'what if' scenarios ) and 
there
is other Non-Apache licensed OpenSource code included in the distribution
then the 'least restrictive license' clause could negate the Apache license.
It's a legitimate concern ( if your mind likes to mull these kinds of legal 
issues )
and I suppose it's the basis for Apache always insisting that any code in the 
Server 
be 'donated' with the official Apache license and no other.

As Edward Albee wrote in Who's Afraid of Viginia Wolf... the only really
safe thing to do is 'Never mix... never worry'. I believe this has always 
been the 'Apache way'.

If enough time has gone by and the need for ZLIB to be in Apache is
now great enough to render all this 'what if' stuff raw bullshit then let's
run that flag up the pole again...

I suggest (again) that the entire ZLIB source code package be IMMEDIATELY
added to the Apache source code tree. Like... TOMORROW.

It seems silly to discuss adding anything like mod_gz ( or our Enhanced
ApacheBench or any built-in IETF Content-encoding support ) unless it is
first determined if either the GZIP source code (GPL license) or ZLIB 
( ZLIB/LIBPNG license) will ever make it into the Apache source tree.

Votes, anyone?

PS: Only Ian's mod_gz or our own Enhanced ApacheBench that can
support IETF Content-encoding would actually NEED any kind of ZLIB
support, AFAIK. Even our own Enhanced ApacheBench does not 
require it because it can compile with/without ZLIB and in the
absence of ZLIB has it's own LZ77 + Huffman decoder. The only reason
we added the ability to use ZLIB was for client-side performance 
testing of the decompression algorithms themselves. It (ZLIB) proved
to be inadequate and we don't recommend i

Re: [PATCH] Add mod_gz to httpd-2.0

[Pier Fumagalli]

"Ryan Bloom" <[EMAIL PROTECTED]> wrote:

> If you want to use gzip, then zip your data before putting it on-line.  That
> doesn't help generated pages, but perl can already do gzip, as can PHP.

And Tomcat 4.x :)

Pier

Re: [PATCH] Add mod_gz to httpd-2.0

[Cliff Woolley]

On Sun, 2 Sep 2001 [EMAIL PROTECTED] wrote:

> Correct... and for a while the reason was because everyone thought the
> module was using ZLIB and there has been a long standing aversion to
> including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
> Apache tree. We have personal emails from your board members stating
> that to be the case. If that aversion has evaporated then there is a TON of
> GNU based stuff that is now 'eligible' for inclusion in the core
> distribution, right?

What Brian said.  Are we talking about the same zlib?  The one I know
about is the one Brian linked to, which is NOT GPL and hence is eligible.
No GPL code is eligible due to the "viral" effect of the GPL on code that
uses it.

> We have said any number of times that even the ORIGINAL version of mod_gzip
> was coded/tested against the ORIGINAL (alpha) release of Apache 2.0.

I know that.  But that was a long, long time ago.  And filters and bucket
brigades have changed a lot since then.  I haven't seen the lastest
version is all I was saying.  I'd really like to.  Please consider sending
me a copy privately so that I can review it.  I'm just interested in a
side-by-side comparison (if there even IS a comparison, which is also
something I'd like to see for myself).

> The moment we are sure that the actual Apache Web Server you are trying to
> use to compress responses is stable and actually able to do the IETF
> Content-encoding without screwing up the responses we will release the code.
> We would prefer GA but decided that, itself, is so far off that we will
> settle for at least 1 known good BETA.

We have a beta out there.  It's 2.0.16.  That said, it's nowhere near as
good as 2.0.26 will be when it's released (assuming no unforseen
catastrophies happen), and many of us tend to just get irritated when
people ask questions about why something doesn't work in 2.0.16.  Beats
the hell out of me... that was ages ago code-wise.  It's probably either
fixed or broken in a different way by now.  :-)  But it's also true that
we're lightyears closer to a stable release now than ever before.

--Cliff


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Sun, Sep 02, 2001 at 01:59:16PM -0700, Ryan Bloom wrote:
> This is not a 3 +1's and it's in issue.  This is a topic currently under
> discussion, and adding it to the server now would be rude.  This is also
> a large enough issue, that it really should be given at least three days for
> people who aren't on list to speak up and have an opportunity to comment.

I was *never* intending to add it without consensus.  I was merely wanting
to clarify a point of order.  Since I am a relative newbie, I am not
sure what the meaning of "+1 (concept)" is.  I now take your position to
be that they do not count.  That is fine with me.  I'm not in a rush
here.  The code isn't going to change.  If the Remote Communications
people happen to submit a patch for inclusion for httpd-2.0, I will
consider that as well.

As I understood it, it requires consensus among the Apache Group
members (the only people who can cast binding votes - but we definitely
solicit other people's comments and suggestions).  We have at this time:

-1 (non-veto): Ryan
+1 (concept): Cliff, Greg, OtherBill
+1 (concept and mod_gz): Justin

(If I'm misrepresenting *anyone*, please let me know...)

Based on the feedback I have received on-list, my +1 for mod_gz stands.

Ryan, you are perfectly free to change your vote to a veto and this 
discussion now becomes tabled.  Unless, of course, we can convince you 
to change your mind.  Or, does this become a majority vote?  Again,
I defer in matters of procedure to those who have been here longer
than I.  This has gotten way of out proportion for a silly little
module.  =-)  -- justin

Re: [PATCH] Add mod_gz to httpd-2.0

[George Schlossnagle]

> In contrast, with an 11,000-line implementation like mod_gzip, it's
> much less likely that other developers will be able to troubleshoot
> the code quickly if it breaks while the original authors are on 
> vacation.

A quick perusal of thesource for the 1.3 version of mod_gzip (which I've 
been happily using for 3 weeks now), leads me to believe that 90% of the 
11,000 lines are debug code #ifdef'd out.

Re: [PATCH] Add mod_gz to httpd-2.0

[Brian Pane]

[EMAIL PROTECTED] wrote:

[...]

>Ryan Bloom responded...
>
>>I have a few problems with this.  1)  We have consistantly declined to
>>accept the mod_Gzip from remote communications.  
>>
>
>Correct... and for a while the reason was because everyone thought the
>module was using ZLIB and there has been a long standing aversion to
>including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
>Apache tree. We have personal emails from your board members stating
>that to be the case. If that aversion has evaporated then there is a TON of
>GNU based stuff that is now 'eligible' for inclusion in the core
>distribution, right?
>
What is "GNU ZLIB"?

The zlib that I know is independent of GNU and has BSE-style licensing:
  http://www.gzip.org/zlib/zlib_license.html

>GNU issues aside... we have consistently been told that the other reason
>mod_gzip would not be included is because of the 'support' issue. Apache
>has a standing rule that no module goes into the distribution unless you
>are absolutely SURE that it will be adequately supported. Makes sense.
>
>We have been consistently supporting this technology for years now.
>Ian himself said he 'Just got bored and decided not to do any real
>work one weekend' and cranked out a filter demo that happened to
>include ZLIB. He has not demonstrated any intention of actually
>'supporting' it other than making a few modifications to the 'demo'
>( and even those have yet to appear ).
>
>If that doesn't raise the issue of 'will it be supported' I don't
>know what would.
>
I think there's a fundamental difference between mod_gz and mod_gzip
in this regard:

If Ian contributes a 450-line mod_gz implementation and decides to never
touch that code again, that's fine.  If the code gets enough +1 votes
to be accepted, it's because at least three other developers have
decided that the code is comprehensible enough for others to debug
and maintain it if it breaks.

In contrast, with an 11,000-line implementation like mod_gzip, it's
much less likely that other developers will be able to troubleshoot
the code quickly if it breaks while the original authors are on vacation.

>mod_gzip has NEVER used 'ZLIB' for a number of reasons... the primary
>one being that ZLIB is inadequate for the purpose. ZLIB is a 
>non-multithread-safe
>file based compression library.
>
 From the README for zlib-1.1.3:

"zlib 1.1.3 is a general purpose data compression library.  All the
 code is thread safe."

--Brian

Re: [PATCH] Add mod_gz to httpd-2.0

[TOKILEY]

Hello all...
Kevin Kiley here...

Here is a mixture of comment/response regarding mod_gzip and the
ongoing conversation(s)...

There is a (short) SUMMARY at the bottom.

Justin ErenKrantz's original post...

> Ian has posted his mod_gz filter before, now I'd like to give it a +1.
>
> I told him I'd look at it a while ago, but never got a chance to do 
> so.  So, I spent this morning cleaning up the configuration and a bit 
> of the code to fit our style (nothing major).
>
> I'd like to add this to the modules/filters directory (which seems
> like the most appropriate place).
>
> Justin

Ryan Bloom responded...

> I have a few problems with this.  1)  We have consistantly declined to
> accept the mod_Gzip from remote communications.  

Correct... and for a while the reason was because everyone thought the
module was using ZLIB and there has been a long standing aversion to
including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
Apache tree. We have personal emails from your board members stating
that to be the case. If that aversion has evaporated then there is a TON of
GNU based stuff that is now 'eligible' for inclusion in the core
distribution, right?

GNU issues aside... we have consistently been told that the other reason
mod_gzip would not be included is because of the 'support' issue. Apache
has a standing rule that no module goes into the distribution unless you
are absolutely SURE that it will be adequately supported. Makes sense.

We have been consistently supporting this technology for years now.
Ian himself said he 'Just got bored and decided not to do any real
work one weekend' and cranked out a filter demo that happened to
include ZLIB. He has not demonstrated any intention of actually
'supporting' it other than making a few modifications to the 'demo'
( and even those have yet to appear ).

If that doesn't raise the issue of 'will it be supported' I don't
know what would.

mod_gzip has NEVER used 'ZLIB' for a number of reasons... the primary
one being that ZLIB is inadequate for the purpose. ZLIB is a 
non-multithread-safe
file based compression library. The secondary reason is actually so 
that you folks wouldn't have to worry about the 'GNU' issues you have if/when
you wanted to use the code. Read the comments at the top of mod_gzip.c
right underneath the Apache license section which has always been at
the top of mod_gzip and the syntax of which was personally approved
by at least 3 of your top level board members via personal email(s).

> 2) I keep hearing that zlib has more memory leaks than a sieve.  

It does. Any non-multithread-safe file oriented library does if you
just slap it into a multithread environment and start using it without
putting critsecs around the calls to serialize it.

> 3)  I don't believe that we
> should be adding every possible module to the core distribution.  

That's always been the rule. It is still a mystery when/how something
'rises' to the level of importance to be included in the Apache
distribution ( E.g. WebDav, etc ). That being said... see next comment.

> I personally think we should leave the core as minimal as possible, and
> only add more modules if they implement a part of the HTTP spec.

mod_gzip does that. It makes Apache able to perform the IETF Content-Encoding
specification that has ALWAYS been a part of HTTP 1.1.

> Before this goes into the main tree, I think we need to seriously think
> about those topics.

Think HTTP 1.1 compliance.

> I would be MUCH happier if this was a sub-project, or just a module
> that Ian distributed on his own.
>
> Ryan


Cliff Wooley wrote...

>> Ryan Bloom wrote...
>>
>> I have a few problems with this.  1)  We have consistantly declined to
>> accept the mod_Gzip from remote communications.
>
> That's true, though that was for 1.3.  Just now with Peter's message is
> the first time I've heard that mod_gzip for 2.0 was even nearing release.
> I'm not prejudiced... whichever one is better wins.  :)

We have said any number of times that even the ORIGINAL version of mod_gzip
was coded/tested against the ORIGINAL (alpha) release of Apache 2.0. It was
only when we realized how long Apache 2.0 was away from either a beta or
a GA that we ported it BACKWARDS to Apache 1.3.x so people could start using
it right away... and they have ( thousands of folks ).

As recently as a few weeks ago we said again that a 2.0 version of mod_gzip
was 'ready to go' but we just wanted to make sure the filtering API's were
going to stop changing ( which they still were at the time ).

Now our only concern is that the filtering I/O is actually WORKING
the way it is supposed to from top to bottom. Even recent messages
regarding Content-length support and such indicate there is still 
some work to be done. We just want the existing Apache 2.0 I/O
scheme to be CERTIFIED by the people that wrote it ( E.g. BETA at least )
before we CERTIFY our own product(s) against that same Server product.

If you were conviced that mod_gzip

Re: [PATCH] Add mod_gz to httpd-2.0

[Ryan Bloom]

On Sunday 02 September 2001 11:07, Justin Erenkrantz wrote:
> On Sun, Sep 02, 2001 at 12:43:09PM -0500, William A. Rowe, Jr. wrote:
> > > The gzip content encoding is part of the HTTP spec.
> >
> > By implementation, or reference?  Sure Content-encoding is part of the
> > spec, and it's defined to allow authors to extend their support to any
> > number of encodings, and forces the server to use only what the client
> > claims as supported encodings.
>
> gzip is mentioned explicitly in RFC 2616 as a supported content-encoding
> (one registered with IANA).
>
> > +1 with caviat to follow.
>
> Cool.  BTW, do these +1 (concept) votes count towards mod_gz's
> inclusion?  I now count three binding +1 (concepts) for this (Cliff,
> Greg, and OtherBill).  Or, do I need to wait until I receive two
> +1s for mod_gz explicitly?

This is not a 3 +1's and it's in issue.  This is a topic currently under
discussion, and adding it to the server now would be rude.  This is also
a large enough issue, that it really should be given at least three days for
people who aren't on list to speak up and have an opportunity to comment.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 12:02 AM


> On 2001-09-01 at 20h50, possibly To [EMAIL PROTECTED] et al.,
> the keyboard of "Ryan Bloom" chattered:
> > 
> > Putting every module into the core is NOT the answer to this problem.
> 
> True.
> 
> > IMNSHO, Apache should be a minamilistic web server.
> 
> IMNSHO, strong disagreement.  It should be able to be configurable
> as minimalist, but that is *not* synonymous with shipping with a
> minimal set of modules.

http://www.zdnet.com/zdnn/stories/news/0,4586,2792860,00.html

Ken, I really _have_ to disagree with you on this count.

> > If we don't need it in the core, it shouldn't be there.
> 
> Again, strong disagreement.  Assuming that by 'core' you mean
> 'standard tarballs and install packages downloadable from apache.org.'

I share your objection Ken.  There is no reason _not_to_ bundle both the
minimalist and comprehensive tarballs (and label them as such.)

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

>> So we need any gzip filter to drop out quick if 1. it knows this mime
type should not be encoded; 2. it sees the 
>> content-encoding is already gz; 3. it sees the uri/filename whatever
in a list of exclusions (that could be 
>> automagically grown when it hits files that
_just_don't_compress_well_.

Items 1 and 2 are already built into mod_gzip

>> But it still burns CPU that we don't want to waste on useless tasks.

Mod_gzip includes logic which prevents it compressing items "deemed" too
small. As for burning CPU, in benchmarking it has been proven (not only
by Apache Bench but also by Mercury Interactive) that it is always
faster to send a smaller file than a larger file. (makes sense) You will
find that the TCP/IP subsystem spends more time (CPU Cycles) outputting
large files (i.e. some javascript files are now over 100K but can be
compressed down to 4K!) than is required by the compression phase and
the transmission phase of a smaller file

>> Probably always need to set some 'threshold' of 8kb (minimally) that
the web server absolutely ignores, and some include >> or exclude list
by mime type to describe the value of further compression.  Even if the
file is requested to be 
>> gzip'ped, and it's targetted for the cache, set a flag at the end
that says "hey, I saved -2% on this file, don't let us >> do _that_
again!  File foo shouldn't be cached", and then internally add foo to
the excludes list for any gzip filter.

See Items 1 & 2 above. This is already built in.

Here is something for this forum if you are really interested in
mod_gzip. Check out this link: http://www.schroepl.net/mod_gzip/

It's an amazing analysis of mod_gzip on HTTP traffic and includes all
different browser types. Here is what is amazing, check out the "saved"
column and the "average" savings for all the different stats... About
51%

That's a HUGE benefit to ALL apache users. Why wouldn't you use it?

Regards


Peter


-Original Message-----
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, September 02, 2001 11:43 AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Add mod_gz to httpd-2.0


From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 4:43 AM


> On Sat, Sep 01, 2001 at 07:50:19PM -0700, Ryan Bloom wrote:
> > On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> > > On Sat, 1 Sep 2001, Ryan Bloom wrote:
> >...
> We ship code that uses it. zlib fixes their code (or somebody else 
> fixes it). Now our module rocks. Chicken and egg... A ton of other 
> projects use zlib. I see no reason for us to avoid it. If it *does* 
> happen to have leaks, then (when somebody finds this to be true) they 
> could fix it.

I kind of wonder about the 'leaks like a sieve' comments.  I wonder if
the actual users are the ones not following the API to cause zlib to
clean up.

Let's not forget ... expat, pcre, and probably zlib have malloc/free fn
ptrs in 
their code.  There is _nothing_ stoping us from using pools to
initialize/mop up 
by thunking for their malloc/free fn ptrs into our pool architecture :)

> > > > 3)  I don't believe that we should be adding every possible 
> > > > module to the core distribution.  I personally think we should 
> > > > leave the core as minimal as possible, and only add more modules

> > > > if they implement a part of the HTTP spec.
> 
> The gzip content encoding is part of the HTTP spec.

By implementation, or reference?  Sure Content-encoding is part of the
spec, and it's defined to allow authors to extend their support to any
number of encodings, and forces the server to use only what the client
claims as supported encodings.

However, gzip is _defined_ by RFC, therefore we have a standards-based
encoding specification, which should be a requirement, IMHO, for
inclusion in any ASF project.

> > > My personal opinion is that this one is important enough that it 
> > > should go in.  Most clients support gzip transfer coding, and it's

> > > a very real solution to the problem of network bandwidth being the

> > > limiting factor on many heavily-loaded web servers and on 
> > > thin-piped clients (read: modem
> 
> Agreed!

+1 with caviat to follow.

> But it isn't "invisible" if you do it with Perl, PHP, Python, or CGI. 
> A person has to explicitly code it.
> 
> I'm really looking forward to mod_gz(ip) in Apache 2.0 so that 
> Subversion can transfer its content in compressed form. All of that 
> comes out of a database... it can't be precompressed, so that leaves a

> filter to do the job as it hits the wire. Doing large checkouts are 
> almost *always* network bound rath

Re: [PATCH] Add mod_gz to httpd-2.0

[Justin Erenkrantz]

On Sun, Sep 02, 2001 at 12:43:09PM -0500, William A. Rowe, Jr. wrote:
> > The gzip content encoding is part of the HTTP spec. 
> 
> By implementation, or reference?  Sure Content-encoding is part of the spec, and
> it's defined to allow authors to extend their support to any number of encodings,
> and forces the server to use only what the client claims as supported encodings.

gzip is mentioned explicitly in RFC 2616 as a supported content-encoding
(one registered with IANA).

> +1 with caviat to follow.

Cool.  BTW, do these +1 (concept) votes count towards mod_gz's 
inclusion?  I now count three binding +1 (concepts) for this (Cliff,
Greg, and OtherBill).  Or, do I need to wait until I receive two
+1s for mod_gz explicitly?

> So we need any gzip filter to drop out quick if 1. it knows this mime type should
> not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the
> uri/filename whatever in a list of exclusions (that could be automagically grown
> when it hits files that _just_don't_compress_well_.

I would think that this is a httpd.conf configuration issue.  Remember,
we add mod_gz via:

AddOutputFilter GZ html

Ian's version did make sure that the content-type was text/html before
encoding.  But, I don't think that is necessary.  If the admin sets
mod_gz via the OutputFilter semantics, that's their wish (remember,
you must *ask* for mod_gz).  I'd rather not see these types of 
assumptions in any gzip module we implement.

(I need to double check that mod_gz and mod_include don't interfere
with each other...mod_gz should run *after* mod_include has processed
the data...)

> If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/
> instead of by reference.  It really isn't that large, and matches what we do today
> with pcre and expat.  If we like, drop it into apr-util/encoding/unix/lib/zlib and
> only expose it through thunks (allowing someone to come up with more robust or faster
> apr-util thunks to source that we can _not_ redestribute.)  The more I contemplate,
> the stronger my +1 for apr-util remapping, where appropriate on some platforms.

Almost every platform I am aware of includes zlib by default now.
Solaris, AIX, Linux, FreeBSD.  Ian has all of the MSVC files (I didn't
post them as I want to place it in modules/filters which is different
than where Ian originally had it) - so I know he has something working
on Win32.  So, I don't think that we need to distribute zlib.  Nor do 
we need to perform "thunking."  It's just so common now.

AIUI, zlibc is completely transparent to any application.  -- justin

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 4:43 AM


> On Sat, Sep 01, 2001 at 07:50:19PM -0700, Ryan Bloom wrote:
> > On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> > > On Sat, 1 Sep 2001, Ryan Bloom wrote:
> >...
> We ship code that uses it. zlib fixes their code (or somebody else fixes
> it). Now our module rocks. Chicken and egg... A ton of other projects use
> zlib. I see no reason for us to avoid it. If it *does* happen to have leaks,
> then (when somebody finds this to be true) they could fix it.

I kind of wonder about the 'leaks like a sieve' comments.  I wonder if the actual
users are the ones not following the API to cause zlib to clean up.

Let's not forget ... expat, pcre, and probably zlib have malloc/free fn ptrs in 
their code.  There is _nothing_ stoping us from using pools to initialize/mop up 
by thunking for their malloc/free fn ptrs into our pool architecture :)

> > > > 3)  I don't believe that we should be adding every possible module to
> > > > the core distribution.  I personally think we should leave the core as
> > > > minimal as possible, and only add more modules if they implement a
> > > > part of the HTTP spec.
> 
> The gzip content encoding is part of the HTTP spec. 

By implementation, or reference?  Sure Content-encoding is part of the spec, and
it's defined to allow authors to extend their support to any number of encodings,
and forces the server to use only what the client claims as supported encodings.

However, gzip is _defined_ by RFC, therefore we have a standards-based encoding
specification, which should be a requirement, IMHO, for inclusion in any ASF project.

> > > My personal opinion is that this one is important enough that it should go
> > > in.  Most clients support gzip transfer coding, and it's a very real
> > > solution to the problem of network bandwidth being the limiting factor on
> > > many heavily-loaded web servers and on thin-piped clients (read: modem
> 
> Agreed!

+1 with caviat to follow.

> But it isn't "invisible" if you do it with Perl, PHP, Python, or CGI. A
> person has to explicitly code it.
> 
> I'm really looking forward to mod_gz(ip) in Apache 2.0 so that Subversion
> can transfer its content in compressed form. All of that comes out of a
> database... it can't be precompressed, so that leaves a filter to do the job
> as it hits the wire. Doing large checkouts are almost *always* network bound
> rather than server/client bound. Compressing those files is a *huge* win.

So we need any gzip filter to drop out quick if 1. it knows this mime type should
not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the
uri/filename whatever in a list of exclusions (that could be automagically grown
when it hits files that _just_don't_compress_well_.

The fact that gzip doesn't _expand_ data is kind of nice.  But it still burns
CPU that we don't want to waste on useless tasks.

> > -1 (vote, not veto), for putting mod_gz in the core.
>
> Needless to say, I'm +1 on the concept. It's a big win for everybody. I
> haven't reviewed the code yet, so no commentary there.

I'm +1 on concept as well, provided we don't keep implementing resuable algorithms
in the core (those are definately apr-util style tasks), we might support both zlib
and zlibc (maybe thunk through apr-util?  I don't see a benefit just yet), and that 
we implement this legibly and simply in as few lines of code as possible.

If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/
instead of by reference.  It really isn't that large, and matches what we do today
with pcre and expat.  If we like, drop it into apr-util/encoding/unix/lib/zlib and
only expose it through thunks (allowing someone to come up with more robust or faster
apr-util thunks to source that we can _not_ redestribute.)  The more I contemplate,
the stronger my +1 for apr-util remapping, where appropriate on some platforms.

The gzip encoding isn't going to change anytime soon.  I'd say that makes it a core
candidate.  If someday later we add 'another' encoding, then that's a new module, and
mod_gzip can keep chugging away.  Or we implement this al la proxy.  mod_encoding for
the generic http encoding field parsing, and encoding_gzip for the backend.

Bill 

p.s. I believe this license is most _definately_ compatible with the ASF, see
http://www.gzip.org/zlib/zlib_license.html

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 10:50 PM


> On Saturday 01 September 2001 20:10, Cliff Woolley wrote:
> >
> > Perhaps modules distributed through official httpd subprojects are more
> > visible/more trusted, but we don't really know one way or the other on
> > that front yet.
>
> I can agree with this, but this is something we need to fix.  There are many
> ways to fix it.  Fixing modules.apache.org would be a very good first step.

++1, we want to _highlight_ our extra projects at http://httpd.apache.org/more/!
And perhaps provide some links from pages like manual/mod/index.html with a
"Not here?  Try the third-party modules, (registered by their authors) 
at http://modules.apache.org/"; for completeness.

> Putting every module into the core is NOT the answer to this problem.  IMNSHO,
> Apache should be a minamilistic web server.  If we don't need it in the core,
> it shouldn't be there.  Personally, I would remove mod_dav from the server too,
> because it doesn't implement part of RFC2616.

I was thinking about this.  We are discussing if /modules/proxy/ should be readded
to the core tree over at [EMAIL PROTECTED]  My observation there is that the
RFC for mod_proxy may be expanded outside of the http schema in the future.  We
already have adjunt Connection-Upgrade/tls over http extensions to that RFC.  This
argument will give us headaches until we decide some simple rules to add a module
as a core or sub project.

WebDAV isn't a 'done' protocol, and really started out as the WebDA protocol
(versioning deferred until we figure out how it should be described.)  I'm sure
it will grow.  mod_ssl isn't 'done' either, until we implement the Connection-Upgrade
schema.  Not only are some folks in the world bound _never_ to download it (as it
is in conflict with their own laws) but some folks in the world are prohibited by
the US from downloading it (the T5).  And it too is supplimented by the TLS RFCs.

One thorn in everyone's side was that mod_proxy implemented a HTTP/1.0 superset, 
although the rest of the server was essentially HTTP/1.1.

IMHO, if a modules is on a different standards track (or likely to be extended on
one) it should probably live in it's own subproject.

Who on the proxy team wants to wait for the core to bump a version "just because
proxy wants us to."  The proxy team finishes implementation of another extension,
they want to get an alpha/beta/release out the door!  If they implement another
proxy-protocol, they want to get that out the door (sftp anyone?)

How about one last example ;-?  Lets say SQL support is deemed 'important'.  An
httpd-sql subproject might implement several aaa modules, with some additional
support/ apps, to allow SQL stuff.  Then they get the hairbrained idea to .htaccess
as a SQL table (for performance.)  This project could grow (with a charter of
'extending httpd core file-based mechanisms through a generic SQL layer') as far
as they wanted to take it.

In a perfect world, apache-2.0.26-gold-core.tar.gz contains just the core.  Then
give the world apache-2.0.26-gold-all-gold-20010915.tar.gz with all _released_ 
subprojects effective 2001.09.15 rolled in!  The adventurous could try the
apache-2.0.26-gold-all-beta-20010915.tar.gz.  Finally, the looney (most folks
that follow this list) can grab apache-2.0.26-gold-all-alpha-20010915.tar.gz
for alpha releases of every module (probably a longer list, since some subprojects
at a given time likely haven't gone gold just yet.)

Subprojects would probably have an easier time with a user of the gold apache core
release, since the bugs are more likely to be _in_ their module, not somewhere
else.  Now we stand a (small) chance of keeping up.

Add some decent user support outside of the (sometime now hard-to-reach) nttp
support in comp.infosystems.www.servers. and these could be really useful.  With
a [EMAIL PROTECTED], [EMAIL PROTECTED], proxy-users... and actually
make that a really strong system, by using mod_mbox on http://httpd.apache.org/
to allow folks to browse those threads.  We must be one of the last strong projects
with _no_ user's list (what's up with that ;-?)

Subprojects shouldn't be our orphans.  The give small author groups well deserved
recognition.  They need to become our crowning jewels.

Bill

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

Ryan Bloom wrote:
> 
> If we don't need it in the core, it shouldn't be there.

Since there is no reason to drive 100+ MPH, auto manufacturers
should not make vehicles capable of going that fast.

'Needed in the core' -- what of the current modules are 'needed
by the core?'  Nothing in the core needs mod_speling, or
mod_rewrite, or...

I think this is a cockeyed metric to use.  Un- or insufficiently-
tested modules, maybe, but shutting things out because of 'core
need'?  I do not think that is valid.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[Rodent of Unusual Size]

Ryan Bloom wrote:
> 
> I believe that putting a module into the core says that we
> are willing to support it, and that we believe the quality of
> the module is as high as the rest of the core.

With that I can certainly agree.

> I would like to make that statement as few times as possible.

See, *that* I would like to say as *many* times as possible,
with equal confidence in all cases.

> The more we say it, the more likely we are to be wrong once.

That sounds like letting 'we should' wait upon 'we dare not.' :-)
I do not know about anyone else, but I personally think the
effort has historically been directed toward making Apache
as featureful and *good* as possible, not making it perfect
and keeping it so small that we limit functionality in order
to keep out the possibility of bugs.  Warts go along with this
stuff.  One of the strong facets has been letting people
work on whatever they want to work on, as long as they were
willing to support it, and nearby eyeballs would help watch for
bugs.  Saying you can do that only within a limited set of
rules is, IMHO, contrary to the spirit of the project.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Jerry Baker" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 10:32 PM


> Ryan Bloom wrote:
> > 
> > You know what's really funny?  Every time this has been brought up before,
> > the Apache core has always said, if you want to have gzip'ed data, then
> > gzip it when you create the site.  That way, your computer doesn't have to
> > waste cycles while it is trying hard to serve requests.  I personally stand by
> > that statement.  If you want to use gzip, then zip your data before putting it
> > on-line.  That doesn't help generated pages, but perl can already do gzip, as
> > can PHP.
> 
> Gzip'ing html into files is a hopeless waste of disk space and clutter.
> That means for every file you have to have a gzipped and non-gzipped
> version for browsers that cannot handle it. Then you have to configure
> Apache to check for and serve the proper file to the proper browser. It
> makes Web page maintenance a severe PITA as you have to re-gzip a doc
> everytime it is modified and upload both files.

Interesting point for gzip authors in general ... if it won't save a second
network packet - it is _not_ worth it (think favicon.ico, icon.gif (or any
self-compressed format), or littleframeset.html).

Probably always need to set some 'threshhold' of 8kb (minimally) that the
webserver absolutely ignores, and some include or exclude list by mime type
to describe the value of further compression.  Even if the file is requested
to be gzip'ped, and it's targetted for the cache, set a flag at the end that
says "hey, I saved -2% on this file, don't let us do _that_ again!  File foo
shouldn't be cached", and then internally add foo to the excludes list for
any gzip filter.

Bill

RE: [PATCH] Add mod_gz to httpd-2.0

[Günter Knauf]

Hi,
> A couple of other issues.

> - Netware. With a little help this can be fixed. However the
I will provide any help I can give; I'm able to compile and run the module, I've 
compiled the debug version and have already sent an output to Kevin; the issue is that 
the work files are always empty...(he assumed that I use SSL but I didnt load any 
other modules except status and info).
> majority of the net runs either Apache, IIS, iPlanet or   Zeus.
yes, I run Apache on NetWare.
> - Debug code and size of mod_gzip... We can remove the debug code.
> It's stable enough now after 9 months of solidtesting to pull it.
I didnt mention it as negative but only to explain why the code is 300kb; 
and it's very useful when the module doesnt run as on NetWare...

If you want to help me a bit in finding out why it doesnt work with NetWare feel free 
to contact me directly...

Thanks, Guenter.

PS: I have also another issue with mod_gzip together with a counter module: when 
mod_gzip is loaded the counter increments 2 times every access (true on all platforms, 
but maybe the counter isnt clean).

RE: [PATCH] Add mod_gz to httpd-2.0

[Peter J. Cranstone]

Hi All,

I think Sander sum it up nicely.

-   It is part of the spec. Apache should implement the spec.
-   Almost all new browsers support IETF content encoding/transfer
encoding. In testing with MSIE 6.x and Netscape 6.1
compression works fine.
-   The biggest users of mod_gzip are outside the USA. Why? Because
they pay for bandwidth.
-   There are some "large" institutions (financial markets) that use
mod_gzip to reduce HTML/JavaScript etc.
-   It supports dynamic and static content.
-   You can compress SSL (with some hacks)

A couple of other issues.

-   Netware. With a little help this can be fixed. However the
majority of the net runs either Apache, IIS, iPlanet or Zeus. 
-   Apache 2.x is not yet stable for all platforms.
-   Debug code and size of mod_gzip... We can remove the debug code.
It's stable enough now after 9 months of solid  testing to pull it.

In closing... Here is the biggest reason to include mod_gzip

-- compression (transfer encoding/content encoding) part of the HTTP
spec! --





Apache's market share dropped last month. Micro$oft IIS 5.0 is making
headway and "IT INCLUDES AN ISAPI GZ FILTER". It happens to be a pig and
it does not support compressed POST transactions (mod_gzip does) and it
has issues compressing Javascript. But bottom line, Microsoft is
supporting the standard and even though the first pass is rough it will
get better. Which means that if people figure out what European users
have been saying for nearly a year that compressing HTML etc really
makes a difference then Apache needs to embrace the light. Mod_gzip was
released with an Apache style license with this thought in mind. The
writing is on the wall, if Micro$oft sees a benefit to adding
compression then it's only a matter of time before everyone is demanding
it be there. My thought is that it would be better for Apache to be
first rather than playing catch up.

On a personal note. Kevin and I have been on this forum long enough to
know what the rules are. We released mod_gzip under an Apache style
license for one reason. So Apache would benefit. Sure Kevin is the
author and has continued to do an incredible job supporting the code,
but now others have joined the mod_gzip forum and have taken up the
challenge. On October 13th 2001 it will have been a year since the code
came out. It has not undergone any changes since March 2001 and is now
considered stable for Apache 1.3.x users. The 2.x version is only
waiting for one thing which is *beta*. What the server is stable enough
to run for months and users are upgrading to the new version we will
release mod_gzip for 2.x under exactly the same license as 1.x version.



Regards


Peter


-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, September 02, 2001 6:12 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Add mod_gz to httpd-2.0


Hi,

>From what I have seen on the list I am on the +1 side of
adding mod_gz(ip) to the distribution.  Ofcourse, my vote doesn't count
since I don't have httpd commit.

I find the following arguments convincing (summarized):

 - The gzip content encoding is part of the HTTP spec.
 - Most clients support gzip transfer coding.
 - It is a real solution to the problem of network bandwidth
   being the limiting factor on many heavily-loaded web servers
   and on thin-piped clients.
 - It makes the compression transparent to the admin of the
   site and allows for dynamically generated content (which
   can grow quite large) to be compressed aswell.

I haven't seen anything that held on the negative side yet.

Sander

RE: [PATCH] Add mod_gz to httpd-2.0

[Günter Knauf]

Hi,
I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32 and it works 
for me. 
The problem I see with 3rd party modules is not mainly that they are 'invisible', I've 
found tons of modules and often 3 or more for the same purpose, but many modules were 
only written for Unix and fail to compile on other platforms because they often 
heavily use system libs which arent available on the new target; so many modules must 
be ported to the target os and the concept of the Apache api is gone. And even if a 
module compiles without changes and no porting is needed it's not guaranteed to run. 
The best sample is mod_gzip: I use it on Linux and Win32, but on NetWare the module 
compiles fine but doesnt work! 
I think this will not happen with Ian's module because it uses only Apache apis, so 
once the server runs on a platform mod_gz will do too (ok, as far as zlib is ported to 
that platform, but that's true for nearly every platform).
I was also in contact with Kevin, but he couldnt help me with the issue on NetWare...

> Ian, I'll chat with Kevin on getting you a copy of the code. Although I
> think he will want to wait until Apache 2.x goes beta. He's the author
> and it's his decision.
please ask Kevin for a copy for me too.

Thanks!

Guenter.

PS: if you take a look at mod_gzip 1.3.xx you will see that more than half of the 300k 
are only debug messages...

Re: [PATCH] Add mod_gz to httpd-2.0

[Daniel Veillard]

On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote:
> zlib has more memory leaks than a sieve.  3)  I don't believe that we
> should be adding every possible module to the core distribution.  I
> personally think we should leave the core as minimal as possible, and
> only add more modules if they implement a part of the HTTP spec.

  though not *required* by the HTTP spec, there is a clear signal
from it that compression should be supported by default. If you
don't believe me, just ask the spec authors !

Daniel

-- 
Daniel Veillard  | Red Hat Network http://redhat.com/products/network/
[EMAIL PROTECTED]  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

RE: [PATCH] Add mod_gz to httpd-2.0

[Sander Striker]

Hi,

>From what I have seen on the list I am on the +1 side of
adding mod_gz(ip) to the distribution.  Ofcourse, my vote
doesn't count since I don't have httpd commit.

I find the following arguments convincing (summarized):

 - The gzip content encoding is part of the HTTP spec.
 - Most clients support gzip transfer coding.
 - It is a real solution to the problem of network bandwidth
   being the limiting factor on many heavily-loaded web servers
   and on thin-piped clients.
 - It makes the compression transparent to the admin of the
   site and allows for dynamically generated content (which
   can grow quite large) to be compressed aswell.

I haven't seen anything that held on the negative side yet.

Sander