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

2001-09-08 Thread 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

2001-09-07 Thread 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)

2001-09-06 Thread 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 :)




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

2001-09-06 Thread 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)

2001-09-06 Thread 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: [PATCH] Add mod_gz to httpd-2.0

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-05 Thread 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

2001-09-04 Thread 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

2001-09-04 Thread 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

2001-09-04 Thread 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

2001-09-04 Thread 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

2001-09-04 Thread 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/



zlib inclusion and mod_gz(ip) recap (was: [PATCH] Add mod_gz to httpd-2.0)

2001-09-04 Thread Greg Stein

On Tue, Sep 04, 2001 at 03:29:04PM -0400, [EMAIL PROTECTED] wrote:
...
 Will the Apache group accept the ZLIB source code
 into the distribution tree at this time?...
 
 [__] Yes
 [__] No

No. The zlib library is popular enough (read: typically installed) that we
will link against it, rather than include it. A Windows installer may bundle
it, though. (yes, zlib *is* available for Windows; Python uses it)

 if ( Yes )
..
 else
   {
 Will Apache accept pre-compiled ZLIB libraries into the
  source tree ( for any/all platforms )?

Definitely not.

...
 if ( Yes )
...
 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?

See above.

 2. How is anything in Apache that ever needs ZLIB supposed to  
 compile? Users must always 'go and get' the libs themselves?

$ rpm -i zlib-devel-1.1.3-6.i386.rpm

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

True. But it is all pretty irrelevant if we use zlib by reference.

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

We haven't need it so far. When we do, then we write some config macros.

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

The regex directives. Regexes are really needed for file pattern handling.
Real world situations usually require some kind of regex matching, so it
went in.

The inclusion of Expat was definitely a chicken/egg thing: the intent was to
make it easier for Apache modules to use XML (given XML's increasing use and
importance; altho it still boggles my mind that we haven't seen mod_soap or
mod_xmlrpc yet... all the blocks are there).

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

It won't go in. No need for it. That hasn't been well-stated, but if you
take a half hour and reread the notes, it kind of surfaces in there. This is
also how we would handle a library like this.

As stated elsewhere, pcre and expat are in there because they aren't
typically available, like zlib is.

 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.

Nothing needs to happen, so it shouldn't be surprising :-). If/when we need
it, then we will include it. As I said, it is just config macros.

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

There are three options on the table:

1) include mod_gzip
2) include mod_gz
3) include neither

I believe there is consensus that (3) is not an option. Despite yours and
Peters pushing and stressing and overbearing sell job to get mod_gz(ip)
type functionality into the core, it was just preaching to the choir. (well,
okay: maybe Ryan didn't want to see it in there :-)  That sell job mostly
served to create an air of hostility.

So now the question comes down to using (1) or (2). People are *not* voting
on including mod_gz because they want to see your alternative. I think it is
pretty much that simple.

But then you say to look at the 1.3 version. That is the problem -- people
don't want to see that. They want to see your 2.0 version, which you already
have working in house. Since you've said it exists, they would rather go
that direction, than have to port the 1.3 version up to 2.0. We're all so
busy, that this kind of laziness is excusable :-) Whether the changes are
large or small, they'd rather see your current work because we already know
the port has been completed and *tested*. We'd have to redo all of that
work, which just seems silly.

So the inclusion of either is blocked on seeing the source to mod_gzip for
Apache 2.0.

Now: you state that you don't want to release it until we hit beta. But that
is not how we work, and you should know that by now. We want the module in
there now, *before* beta hits. You say that you don't want to release it
while the APIs are in flux -- that they should be stable. But that is bogus.
If we include mod_gzip *today*, then it will get fixed along with everything
else as we change the APIs. You aren't going to be responsible for keeping
it up to date with the changes. We are. That is part of what going into the
core means 

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

2001-09-04 Thread 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/



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-04 Thread 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







Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-04 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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 is here to stay.

I'm glad that Apache has proven itself to be 

Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-03 Thread 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

2001-09-03 Thread 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 http://thomas.eibner.dk/ DnsZone http://dnszone.org/
  mod_pointer http://stderr.net/mod_pointer 




Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-03 Thread 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

2001-09-02 Thread Justin Erenkrantz

On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote:
 On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
 
 I have a few problems with this.  1)  We have consistantly declined to
 accept the mod_Gzip from remote communications.

mod_gzip implements the gzip algorithm.  It also happens to be a 300k 
source file (~11,000 lines).  mod_gz is a 14k file and is 446 lines 
and relies on zlib.

Knowing the people on this list I will bet that the size of the file 
went a long way for us not accepting Remote Communications's version 
in the core distribution.  My cause for not accepting mod_gzip would
be that implementing the gzip algorithm is better left to someone
else - like the guy who wrote gzip.  I mean no offense to Remote
Communications as I'm sure their implementation is sound.

I will accept the most concise and correct version - at this time, 
Ian's version is the only one being offered.  (My one complaint
about mod_gz is that it needs to be moved out of Eastern Europe.)

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

As Cliff has pointed out, if there are memory leaks in zlib, then
this will sniff them out.  Both Opera and Mozilla rely on zlib for 
handling their gzip Transfer-Encoding.  I am sure that their products
would benefit if the Apache Group can fix their memory leaks.

There hasn't been a release of zlib since 1998.  I'm not concerned 
about this (because if there were memory leaks, *someone* would have
addressed them by now).  I'm also not amused by the suggestion that 
this may be a security hole.  This is a read-only operation that 
we are performing.

   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.

I believe that this does implement a core component of the HTTP spec
- namely Transfer-Encoding.  Most current browsers have gzip support 
built-in (Netscape, Opera, and Mozilla do - I bet IE does, but I 
don't use it) - however, we have never supported this.  I believe it
is time that we do so.  Not having implemented this is a major 
oversight on our part.

 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 believe that DAV belongs in our standard module set because it is 
treated as an extension to HTTP.  The same goes for our inclusion 
with SSL.

I believe that anything that adds value to the server out-of-the-box
belongs in the main repository.  Things like mod_pop3 and mod_mbox
are special modules that no one really cares much about.  We did them
as proofs of concepts - if they help, cool, but they aren't part of
the officially supported httpd-2.0 code - you don't want to maintain
or enhance mod_pop3 and I don't want to maintain or enhance mod_mbox.

My +1 for adding this to the core distribution of modules stands.
I fully believe that adding this functionality to the server is
completely worth it.

Can I either receive two more +1s or a straight out veto?  (AIUI,
a non-veto -1 is treated as a -0.  Please correct me if I am wrong.)
-- justin




Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-02 Thread Eli Marmor

Justin Erenkrantz wrote:

 mod_gzip implements the gzip algorithm.  It also happens to be a 300k
 source file (~11,000 lines).  mod_gz is a 14k file and is 446 lines
 and relies on zlib.
 
 Knowing the people on this list I will bet that the size of the file
 went a long way for us not accepting Remote Communications's version
 in the core distribution.  My cause for not accepting mod_gzip would
 be that implementing the gzip algorithm is better left to someone
 else - like the guy who wrote gzip.  I mean no offense to Remote
 Communications as I'm sure their implementation is sound.

If I recall correctly, this "guy who wrote gzip" (or - to be precise -
one of the two guys who wrote it) is working with Remote Communications.

If it's true, it means that he feels OK with their implementation (maybe
it's similar?). Having one less library to depend on, is an advantage and
not a disadvantage, even if it requires mod_gzip to be 300K (I believe
that the 2.0 version will be smaller, thanks to the I/O filtering).

Maybe we should simply ask him; His name is Mark Adler, more details at:
http://www.alumni.caltech.edu/~madler/

Note: I don't know mod_gz but only mod_gzip.
-- 
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

2001-09-02 Thread Greg Stein

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:
...
   2)  I keep hearing that zlib has more memory leaks than a sieve.
 
  Maybe it does, but that can be dealt with.  Even so, it shouldn't be a
  consideration here IMO, at least not yet.  If it really is leaky (which it
  very well might be but we should prove it rather than just going on what
  we heard), then it's a consideration, but it'd be better for somebody to
  just *fix* zlib than for us to throw out both mod_gz and mod_gzip because
  of zlib's deficiencies (assuming we care, which we probably do).
 
 I disagree that this shouldn't be a consideration.  If we are distributing a module
 that relies on a library that leaks, then we are suggesting people use a leaking
 library.  I would be fine fixing zlib, but if that can't be done, then a memory leak
 in zlib would make me a -0.5 very quickly.

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.

   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. 

  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!

  users).  mod_gz(ip) could provide a significant throughput improvement in
  those cases, where the CPU is twiddling its thumbs while the network pipe
  is saturated.  This fills a gap in Apache that could be a very big deal to
  our users.  (It's not like it's a big or obtrusive module either, but size
  is not the final consideration in what goes in and what doesn't.)
 
 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.

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.

 -1 (vote, not veto), for putting mod_gz in the core.

Please use -0.9 or something. It gets really confusing to see -1 and never
know what it means. As I've said before: -1 really ought to always mean a
veto. But... that's just me :-)


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.

Cheers,
-g

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



RE: [PATCH] Add mod_gz to httpd-2.0

2001-09-02 Thread 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



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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! --

for those who hate long emails you can stop reading here

soap box

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.

end

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

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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

2001-09-02 Thread 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 was only for Apache 1.3.x then 

Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-02 Thread 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

2001-09-02 Thread 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




[PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Justin Erenkrantz

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

Can I get two other +1s?  I've reviewed the code and can get it
confirmed working with Netscape 4.77 and Mozilla 0.9.3 by adding the 
following to httpd.conf:

IfModule mod_gz.c
GZFilter On
AddOutputFilter GZ html
/IfModule

We could remove GZFilter as it really serves no purpose as well as the 
text/html check in mod_gz.  I'd like to commit something that is close
to what Ian originally submitted and then tweak it slightly.

(Interesting to note that Netscape 4.77 does not allow you to view
the source of a gzipped'd entity while Mozilla shows you the
decompressed entity.  Mozilla is getting cool...)

I'm sure we can do more analysis of its performance (what the
appropriate deflation settings should be), but I'd really to get
this in first.  =-)  Please test and report back...  -- justin

Index: config.m4
===
RCS file: /home/cvs/httpd-2.0/modules/filters/config.m4,v
retrieving revision 1.6
diff -u -r1.6 config.m4
--- config.m4   2001/05/12 03:48:31 1.6
+++ config.m4   2001/09/01 21:38:16
@@ -6,6 +6,55 @@
 
 APACHE_MODULE(include, Server Side Includes, , , yes)
 
+APACHE_MODULE(gz, GZip encoding support, mod_gz.lo, , most, [
+  AC_ARG_WITH(z, [  --with-z=DIR  use a specific zlib library],
+  [
+if test x$withval != xyes  test x$withval != x; then
+  ap_zlib_base=$withval
+fi
+  ])
+  if test x$ap_zlib_base = x; then
+AC_MSG_CHECKING([for zlib location])
+AC_CACHE_VAL(ap_cv_zlib,[
+  for dir in /usr/local /usr ; do
+if test -d $dir  test -f $dir/include/zlib.h; then
+  ap_cv_zlib=$dir
+  break
+fi
+  done
+])
+ap_zlib_base=$ap_cv_zlib
+if test x$ap_zlib_base = x; then
+  enable_gz=no
+  AC_MSG_RESULT([not found])
+else
+  AC_MSG_RESULT([$ap_zlib_base])
+fi
+  fi
+  if test $enable_gz != no; then
+ap_save_includes=$INCLUDE
+ap_save_ldflags=$LDFLAGS
+ap_save_libs=$LIBS
+if test $ap_zlib_base != /usr; then
+  APR_ADDTO(INCLUDES, [-I${ap_zlib_base}/include])
+  APR_ADDTO(LDFLAGS, [-L${ap_zlib_base}/lib])
+  if test x$ap_platform_runtime_link_flag != x; then
+ APR_ADDTO(LDFLAGS, [$ap_platform_runtime_link_flag${ap_zlib_Base}/lib])
+  fi
+fi
+APR_ADDTO(LIBS, [-lz])
+AC_MSG_CHECKING([for zlib library])
+AC_TRY_LINK([#include zlib.h], [return Z_OK;], 
+[AC_MSG_RESULT(found) 
+ AC_CHECK_HEADERS(zutil.h)],
+[AC_MSG_RESULT(not found)
+ enable_gz=no
+ INCLUDES=$ap_save_includes
+ LDFLAGS=$ap_save_ldflags
+ LIBS=$ap_save_libs])
+  fi
+])
+
 APR_ADDTO(LT_LDFLAGS,-export-dynamic)
 
 APACHE_MODPATH_FINISH

Index: mod_gz.c
===
/* 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2000-2001 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution,
 *if any, must include the following acknowledgment:
 *   This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/).
 *Alternately, this acknowledgment may appear in the software itself,
 *if and wherever such third-party acknowledgments normally appear.
 *
 * 4. The names Apache and Apache Software Foundation must
 *not be used to endorse or promote products derived from this
 *software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called Apache,
 *nor may Apache appear in their name, without prior written
 *permission of the Apache Software Foundation.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY 

Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Ryan Bloom

On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:

I have a few problems with this.  1)  We have consistantly declined to
accept the mod_Gzip from remote communications.  2)  I keep hearing that
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.

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

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

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



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Cliff Woolley

On Sat, 1 Sep 2001, Ryan Bloom wrote:

 On Saturday 01 September 2001 14:56, Justin Erenkrantz 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.  :)

I don't suppose the guys at Remote Communications would be willing to
share the code for mod_gzip for 2.0 with some of us developers privately
so that we can get a feel for it before it's released publicly, would
they?

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

Maybe it does, but that can be dealt with.  Even so, it shouldn't be a
consideration here IMO, at least not yet.  If it really is leaky (which it
very well might be but we should prove it rather than just going on what
we heard), then it's a consideration, but it'd be better for somebody to
just *fix* zlib than for us to throw out both mod_gz and mod_gzip because
of zlib's deficiencies (assuming we care, which we probably do).

 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.

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
users).  mod_gz(ip) could provide a significant throughput improvement in
those cases, where the CPU is twiddling its thumbs while the network pipe
is saturated.  This fills a gap in Apache that could be a very big deal to
our users.  (It's not like it's a big or obtrusive module either, but size
is not the final consideration in what goes in and what doesn't.)

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA








Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread William A. Rowe, Jr.

From: Pier Fumagalli [EMAIL PROTECTED]
Sent: Saturday, September 01, 2001 8:57 PM


 Ryan Bloom [EMAIL PROTECTED] 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.
 
 I can't say much, as I'm not a developer of HTTPD, but I tend to share the
 feeling with Ryan on this. In the light of the latest security warnings on
 Tomcat, adding a single feature (CGI execution), compromised our entire
 core... And as Chuck forwarded to the members, it might be worth reading
 this http://www.zdnet.com/zdnn/stories/news/0,4586,2792860,00.html.
 
 Adding features to the core, unless they're absolutely 100% safe and 100%
 needed is, IMVVVHO, not a very good idea...

I concur.  I'd also point out that the more thoroughly we can document the new
hooks architechture, and expose the apr/apr-util/libhttpd api to the third party
developers, the more secure their modules stand to be.

By instituting additional internal interlocks (e.g. the request must have the
dir_walk/file_walk success tag before the core handler will work) and a very
predictable schema, that is successfully optimized, module authors won't spend
as much time hacking 'around' the core, and we will all enjoy significantly fewer
new holes in 2.0.

Let's make 2.0 the most _predictable_ release ever, and everyone benefits :-)

Bill




Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Ryan Bloom

On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
 On Sat, 1 Sep 2001, Ryan Bloom wrote:
  On Saturday 01 September 2001 14:56, Justin Erenkrantz 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.  :)

Remote Communications has been very vocal about having ported to 2.0
for a very long time.

 I don't suppose the guys at Remote Communications would be willing to
 share the code for mod_gzip for 2.0 with some of us developers privately
 so that we can get a feel for it before it's released publicly, would
 they?

Their code has always been open source.  Their 1.3 code is basically
based on code from Krow at /. 

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

 Maybe it does, but that can be dealt with.  Even so, it shouldn't be a
 consideration here IMO, at least not yet.  If it really is leaky (which it
 very well might be but we should prove it rather than just going on what
 we heard), then it's a consideration, but it'd be better for somebody to
 just *fix* zlib than for us to throw out both mod_gz and mod_gzip because
 of zlib's deficiencies (assuming we care, which we probably do).

I disagree that this shouldn't be a consideration.  If we are distributing a module
that relies on a library that leaks, then we are suggesting people use a leaking
library.  I would be fine fixing zlib, but if that can't be done, then a memory leak
in zlib would make me a -0.5 very quickly.

  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.

 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
 users).  mod_gz(ip) could provide a significant throughput improvement in
 those cases, where the CPU is twiddling its thumbs while the network pipe
 is saturated.  This fills a gap in Apache that could be a very big deal to
 our users.  (It's not like it's a big or obtrusive module either, but size
 is not the final consideration in what goes in and what doesn't.)

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.

-1 (vote, not veto), for putting mod_gz in the core.

Ryan

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



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Cliff Woolley

On Sat, 1 Sep 2001, Ryan Bloom wrote:

 Their code has always been open source.  Their 1.3 code is basically
 based on code from Krow at /.

I know that.  But the 2.0 version is supposed to be vastly different
(less complex) than the 1.3 version, from what I remember.  I'd just like
to see it.  shrug

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Cliff Woolley


Taking a step back from gz for a moment, and speaking in general:


On Sat, 1 Sep 2001, Ian Holsman wrote:

 3rd party modules are invisible to most people,

I'll agree with that statement... we can tell ourselves that it's okay to
push off modules onto third-party distribution, but the fact is that if it
doesn't come as a standard module, people are much less likely to go get
it unless they have absolutely no other choice because they either are too
lazy, don't know it exists, or fear its stability/security because it's
third-party.

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.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Jerry Baker

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.

-- 
Jerry Baker

PGP Key: http://www.jerrybaker.org/pgp.html

LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/



RE: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Padwa, Daniel

 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.

A couple of points here

- a lot of authors can't easily zip content before putting it on-line.
Most people don't update Web sites via makefiles/scripts/whatever that can
easily be extended to zip for them.   A lot of people use FrontPage or the
Windows Web Publishing Wizard - good luck explaining how to run gizp.
Remember - most users of Apache are not software develoeprs.

- a LOT of third party tools make it really hard to insert gzip output
filters in the right place.   Last I checked Tomcat 3.X did not support this
without hacking at their classes.Other JSP engines are even worse.
Don't even start thinking about some of the more pricey site-management
suites.

I haven't studied either of these two modules in depth, but the lack of a
simple negotiate on gzip encoding for text/html option has been a major
flaw in most (all?) Web servers to date.   Putting one of these in the
default Apache distribution would be a wonderful thing.

- Danny



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Ryan Bloom

On Saturday 01 September 2001 20:10, Cliff Woolley wrote:
 Taking a step back from gz for a moment, and speaking in general:

 On Sat, 1 Sep 2001, Ian Holsman wrote:
  3rd party modules are invisible to most people,

 I'll agree with that statement... we can tell ourselves that it's okay to
 push off modules onto third-party distribution, but the fact is that if it
 doesn't come as a standard module, people are much less likely to go get
 it unless they have absolutely no other choice because they either are too
 lazy, don't know it exists, or fear its stability/security because it's
 third-party.

 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.

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.

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



Re: [PATCH] Add mod_gz to httpd-2.0

2001-09-01 Thread Rodent of Unusual Size

On 2001-09-01 at 18h19, possibly To [EMAIL PROTECTED] et al.,
the keyboard of Ryan Bloom chattered:
 
 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.

I strongly disagree with that concept.  Incredibly strongly. :-)
I think module inclusion eligibility should be based on utility
and support, and not on anything as limited as protocol relativity.
-- 
#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

2001-09-01 Thread Rodent of Unusual Size

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.

 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.'
-- 
#kenP-)}

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

All right everyone!  Step away from the glowing hamburger!