You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by TO...@aol.com on 2001/09/05 09:56:32 UTC
Re: zlib inclusion and mod_gz(ip) recap
Greg Stein wrote...
> > Kevin Kiley asked...
> >
> > 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...
It has now, it seems ( finally! ).
Only takes one veto and looks like between you ( and/or Ryan )
there will never be any ZLIB sources in Apache. End of story.
Good to know.
> As stated elsewhere, pcre and expat are in there because they aren't
> typically available, like zlib is.
Ah... so that's the criteria? Ok.
I believe the other libs you mention have been 'tweaked'
and that's another reason why the source is there, yes?
What if you ever need to 'tweak' ZLIB because it was never
really designed to be a real-time data compression engine?
Would that remove the 'no ZLIB source' dictum?
> Nothing needs to happen, so it shouldn't be surprising :-). If/when we need
> it, then we will include it. As I said, it is just config macros.
You are putting an awful lot of faith in ZLIB and the assumption that it
will suit your needs 'out of the box' but I hear ya...
> There are three options on the table:
>
> 1) include mod_gzip
> 2) include mod_gz
> 3) include neither
>
> I believe there is consensus that (3) is not an option.
Huh?
I didn't see any real consensus on that.
Only a real vote will tell you that.
Why note call for one?... not a vote on any particular piece of code
but whether or not to include anything to do with IETF Content-Encoding
into the actual CORE or standard module base ( for now ).
That will tell the story about option 3 for sure.
Ryan himself said he prefers 3 right off the bat when Jerry
said 'Let's dump Ian's mod_gz into the core!' which is what
started this whole entire thread.
His (Ryan's) preference is that for the time being ( and I'm beginning to
lean that
way myself in light of this discussion ) is just leave the IETF
Content-Encoding
stuff out of the core and let 3rd party modules handle it. That'll work.
That's the way it works right now and thousands of real Apache users don't
seem to have a problem with that.
No one ( including myself ) has made any kind of airtight case
yet as to WHY IETF Content-Encoding support SHOULD be in
the core Server itself. I am not sure I could, at this point, after
seeing that anyone who really wants to compress responses
knows how to locate and install a module that will do so ( mod_gzip ).
I guess it would be easier for folks to 'get' it in the tarball but that
hasn't stopped
a few thousand people finding/using mod_gzip over the last year or so even I
have
to admit putting it all in the core doesn't seem like a house on fire.
> Despite yours and
> Peters pushing and stressing and overbearing "sell job" to get mod_gz(ip)
> type functionality into the core, it was just preaching to the choir. (well,
> okay: maybe Ryan didn't want to see it in there :-) That sell job mostly
> served to create an air of hostility.
Yea... okay... whatever... we are the 'bad guys' again for trying to
improve your Server. Mea Culpa.
> 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.
Yea... I guess.
> But then you say to look at the 1.3 version.
What I meant was... if anyone wants to see right away if a whole bunch
of pure 'coding style' bullshit is going to be the show stopper right off the
bat then there's no need to wait for anything. As I have said 3 times now...
it doesn't take rocket scientist to look at an existing module and imagine
what it will STILL look like with filtering calls in it.
I assure you... I did not rewrite the 1.3.x module just for 2.0. All I did
was add the filtering calls. It was no big deal.
Ian himself could have probably done the same in less time than it took
him to write the mod_gz demo in the first place.
I also haven't gotten an answer to my question regarding the weird comment
that appeared in this discussion about any module being submitted that
supports both 1.3.x AND 2.0 in the same code ( which the mod_gzip I have
here certainly does ) will be rejected for that reason alone.
Is that true?
If so... then this is all a moot point. I don't have the time at the moment
to hack up a perfectly fine module that supports ALL versions of Apache
into something that ONLY cares about Apache 2.0. I am not even
sure I would... it seems like a really stupid thing to do.
> 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.
Yep... sure would be.
> So the inclusion of either is blocked on seeing the source to mod_gzip for
> Apache 2.0.
Not really...
The vote about mod_gz was still in progress.
It was about to 'pass', I think. Why not start it over again and
see if it actually does?
Maybe a legal majority doesn't give a crap about seeing any
other code and would rather see Ian's mod_gz drop in the core right now.
Majority rules here, right?
I think Jerry's whole reason for saying 'let's go for it' was because he
is seeing screwy things trying to use a filter like mod_gz and mod_include
together and he wants to drop it in to have something to test with or
something like that. If dropping mod_gz in RIGHT NOW somehow helps
figure out the remaining filter problems then what the hell... go for it.
Finding any/all remaining problems with the filtering itself should be
the real priority in this ALPHA stage, yes?
> Now: you state that you don't want to release it until we hit beta. But
that
> is not how we work, and you should know that by now.
Sorry... I must have missed that part of the Apache developer's guide.
That is most certainly NOT how I thought you worked.
I thought the idea of adding new modules in the 11th hour before a
beta when you are still diagnosing I/O issues and/or multithreading
issues would have historically been a real downer for you guys.
> We want the module in there now, *before* beta hits.
Then fer chrissakes just drop Ian's demo in. It can be replaced
later if you find something better. You've done it before.
> You say that you don't want to release it
> while the APIs are in flux -- that they should be stable. But that is
bogus.
> If we include mod_gzip *today*, then it will get fixed along with
everything
> else as we change the APIs. You aren't going to be responsible for keeping
> it up to date with the changes. We are. That is part of what going into the
> core means -- that we have an obligation and responsibility to maintain it.
> And we will. If it goes in.
Okay... now you are blowing my mind.
Whenever we have tried to submit ANYTHING to you guys before all we got was
the direct opposite. If someone submitted a module in the next hour that
was the greatest thing since sliced bread but said 'I expect you to take this
as-is and not bother me anymore' you would normally just say 'yea... right...
get
outta town'.
You seem to be missing something here, Greg. If WE submit anything to
Apache and it is accepted then WE certainly plan on helping to maintain
it. If we feel ( as a company ) that we don't have the time to do so then
it's never going to darken your door. That's the way it is and the way I
have always understood the Apache (module) submission process to be.
> Summary:
>
> * zlib is not going to be included in any fashion, we'll use it by
reference
> if/when we need to
Roger that.
> * you should release your 2.0 mod_gzip so that everybody can make an
> informed decision about putting compression functionality into Apache
Agreed. It's the timing that is the only issue.
> * if mod_gzip goes in, then it would do so earlier rather than later, and
we
> will deal with any API changes that occur between now and ship -- it
isn't
> your burden to bear, so there shouldn't be a reason to withold.
We wanted a GA before we got involved with 2.0. That just makes
good business sense. Looks like that's still a LOOONG way off.
Then at least go BETA. Express confidence in your own product...
and you will see a lot of other submissions ( not just mod_gzip ).
Between BETA and SHIP you will get the chance to do whatever you
want... even pull things out.
If the upcoming beta ( WHEN?? ) absolutely MUST have a GZ filter
in the core ( for whatever reason that is ) then just go ahead and dump
Ian's demo in the core.
No one has even tested it enough to say whether it really works well or not...
but it just might!
Later...
Kevin
Re: zlib inclusion and mod_gz(ip) recap
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 06, 2001 at 08:54:58AM -0700, Doug MacEachern wrote:
> On Wed, 5 Sep 2001, Greg Stein wrote:
>
> > mod_gz is just a little bugger off to the side that the core people don't
> > have to truly worry about.
> ...
> > It can go in now and be fixed over time.
> ...
> > modules which have *nothing* to do with stability.
>
> so you're saying mod_gz would go into modules/experimental ?
If you're opposed to modules/filters, then sure. That is actually a pretty
decent place to put it while it is worked on.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: zlib inclusion and mod_gz(ip) recap
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 5 Sep 2001, Greg Stein wrote:
> mod_gz is just a little bugger off to the side that the core people don't
> have to truly worry about.
...
> It can go in now and be fixed over time.
...
> modules which have *nothing* to do with stability.
so you're saying mod_gz would go into modules/experimental ?
Re: zlib inclusion and mod_gz(ip) recap
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 05, 2001 at 11:05:50AM -0700, Doug MacEachern wrote:
> On Wed, 5 Sep 2001, Ryan Bloom wrote:
> > > > Ryan himself said he prefers 3 right off the bat when Jerry
> > > > said 'Let's dump Ian's mod_gz into the core!' which is what
> > > > started this whole entire thread.
> > >
> > > Ask him what he thinks now :-) Knowing Ryan, he is probably fine with
> > > adding it at this point.
> >
> > Nope. My opinion hasn't changed. I won't veto, but I continue to think
> > this is a bad idea.
>
> i have the same opinion, for the same reason i was stunned (and still
> am) to see ldap modules in the 2.0 tree.
That was a surprise to me, too. I was out during July. I thought we would
have some simple ldap stuff in APRUTIL... not a huge codebase in httpd.
(when I discussed a division of the code, I was expecting a separate vote
for adding mod_ldap to httpd-2.0, which I would then vote against :-) Since
then, I had also thought we agreed to move mod_ldap *out* of the core, into
httpd-ldap.
To make all of this workable, I just recently posted a thought on how to
deal with rollup releases. No comments appeared on that yet, tho.
> new modules at this point are
> only going to further delay the release of 2.0, hell even discussing
> adding new modules is contributing to the delay.
If Ian is not assisting with stabilizing the httpd core, then how could his
work on mod_gz delay the core? IOW, he is not "subtracting" anything from
the stabilization process. If the argument is that people who *are*
stabilizing the core will now be distracted... that is their problem :-)
mod_gz is just a little bugger off to the side that the core people don't
have to truly worry about. It will get enough attention from the "fringe"
people, if you will (my pardons to people who were just called fringe :-).
> i do think apache should be bundled with one or the other (mod_gz or
> mod_gzip), but it should wait until 2.1. i'm pretty sure most people
> (myself included), are most interested in being able to just use 2.0
> feature-wise as-is and won't mind waiting until 2.1+ for new features.
Introducing mod_gz isn't going to slow down a 2.0 release. And it *is* a
part of RFC 2616, supported by a bunch of browsers, and it is definitely
missing functionality (re: its lack was pasted over by mod_perl's and PHP's
band-aid solution to compression).
> we're in the 9th month of year 2001, i saw the first glimpse of a '2.0'
> server in early 1996 (rob thau's), i have no problem waiting longer for
> bug fixes, performance, "doing things right", etc., but there is no good
> reason to add new modules or big features at this point. they should wait
> for 2.1+.
If people want a stable server, then they should work on that, and not pay
attention to mod_gz within the server. It should be stable enough, and it
*does* simply use the existing module and filter interfaces. Why should core
people worry about it? It can go in now and be fixed over time.
There are a good number of people in this group, and each of those people
concentrate on different items, for different reasons. If you want a stable
server, with a sooner-than-later release, then concentrate on the core. Some
of those other people will work on modules which have *nothing* to do with
stability. If the core developers are distracted by mod_gz, then that is
their own fault, not the fault of introducing a new module.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: zlib inclusion and mod_gz(ip) recap
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 05 September 2001 11:09, Graham Leggett wrote:
> Doug MacEachern wrote:
> > we're in the 9th month of year 2001, i saw the first glimpse of a '2.0'
> > server in early 1996 (rob thau's), i have no problem waiting longer for
> > bug fixes, performance, "doing things right", etc., but there is no good
> > reason to add new modules or big features at this point. they should
> > wait for 2.1+.
>
> Then where is the v2.1 development tree?
>
> v2.0 represents the latest bleeding egde server development. Until a
> v2.1 development tree exists then there is no choice but to commit
> things to v2.0.
That is bunk. If you want to start 2.1, then just say so, and we can create
a 2.1 repository. I would warn you that doing that means you have to keep
the two in sync, which sucks, big time. Otherwise, just commit mod_gzip to
an external repository, and add a note to the 2.0 STATUS file that when we
go to 2.1, it should be moved to the 2.1 tree.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: zlib inclusion and mod_gz(ip) recap
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 05 September 2001 11:27, Graham Leggett wrote:
> Doug MacEachern wrote:
> > for new modules? no, you create a separate tree for the new module
> > (either on apache.org or sourceforge or your own laptop or wherever).
> > if the httpd-2.0 tree needs tweaking for smooth integration of a new
> > module, that's fine.
>
> That's wonderful news for users. No longer do they download the tarball,
> build it, and enable the features they want, now they trawl the web
> looking for this module and that module - assuming they even know the
> modules exist in the first place.
>
> We need to keep things simple from a user perspective, and not just
> focus on keeping things simple from a developers perspective.
What trawl the web? Register the thing with modules.apache.org, and then
all users just go there. If modules.apache.org isn't good enough, then let's
fix that problem.
Again, rolling EVERY possible module into one Apache dist is not the solution
to the module problem. It is a band-aid to the problem.
If the only reason to include the module in the core is so that users don't have
to trawl the web, then I will veto it right now. That is NOT a valid reason to
include the module in the core IMNSHO.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: zlib inclusion and mod_gz(ip) recap
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 5 Sep 2001, Graham Leggett wrote:
> That's wonderful news for users. No longer do they download the tarball,
> build it, and enable the features they want, now they trawl the web
> looking for this module and that module - assuming they even know the
> modules exist in the first place.
>
> We need to keep things simple from a user perspective, and not just
> focus on keeping things simple from a developers perspective.
'no longer' ? ldap and gzip were never part of the 1.3 bundle.
have you not seen apachetoolbox.com? according the site "63 3rd party
modules" are included. are you suggesting we add all of those to the
httpd-2.0 bundle to "keep things simple"? that project solves the
problems you site here, i assume they will do the same for 2.0 once it is
released.
anyhow, you've totally missed my point. my only concern is timing. i'm
not at suggesting which modules should or should not be part of the core.
i'm only saying it should have been decided long ago which modules are
going into the 2.0 core. anything else should wait for 2.1+.
Re: zlib inclusion and mod_gz(ip) recap
Posted by Graham Leggett <mi...@sharp.fm>.
Doug MacEachern wrote:
> for new modules? no, you create a separate tree for the new module
> (either on apache.org or sourceforge or your own laptop or wherever).
> if the httpd-2.0 tree needs tweaking for smooth integration of a new
> module, that's fine.
That's wonderful news for users. No longer do they download the tarball,
build it, and enable the features they want, now they trawl the web
looking for this module and that module - assuming they even know the
modules exist in the first place.
We need to keep things simple from a user perspective, and not just
focus on keeping things simple from a developers perspective.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: zlib inclusion and mod_gz(ip) recap
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 5 Sep 2001, Graham Leggett wrote:
> v2.0 represents the latest bleeding egde server development. Until a
> v2.1 development tree exists then there is no choice but to commit
> things to v2.0.
for new modules? no, you create a separate tree for the new module
(either on apache.org or sourceforge or your own laptop or wherever).
if the httpd-2.0 tree needs tweaking for smooth integration of a new
module, that's fine.
Re: zlib inclusion and mod_gz(ip) recap
Posted by Graham Leggett <mi...@sharp.fm>.
Doug MacEachern wrote:
> we're in the 9th month of year 2001, i saw the first glimpse of a '2.0'
> server in early 1996 (rob thau's), i have no problem waiting longer for
> bug fixes, performance, "doing things right", etc., but there is no good
> reason to add new modules or big features at this point. they should wait
> for 2.1+.
Then where is the v2.1 development tree?
v2.0 represents the latest bleeding egde server development. Until a
v2.1 development tree exists then there is no choice but to commit
things to v2.0.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: zlib inclusion and mod_gz(ip) recap
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 5 Sep 2001, Ryan Bloom wrote:
>
> > > Ryan himself said he prefers 3 right off the bat when Jerry
> > > said 'Let's dump Ian's mod_gz into the core!' which is what
> > > started this whole entire thread.
> >
> > Ask him what he thinks now :-) Knowing Ryan, he is probably fine with
> > adding it at this point.
>
> Nope. My opinion hasn't changed. I won't veto, but I continue to think
> this is a bad idea.
i have the same opinion, for the same reason i was stunned (and still
am) to see ldap modules in the 2.0 tree. new modules at this point are
only going to further delay the release of 2.0, hell even discussing
adding new modules is contributing to the delay.
i do think apache should be bundled with one or the other (mod_gz or
mod_gzip), but it should wait until 2.1. i'm pretty sure most people
(myself included), are most interested in being able to just use 2.0
feature-wise as-is and won't mind waiting until 2.1+ for new features.
we're in the 9th month of year 2001, i saw the first glimpse of a '2.0'
server in early 1996 (rob thau's), i have no problem waiting longer for
bug fixes, performance, "doing things right", etc., but there is no good
reason to add new modules or big features at this point. they should wait
for 2.1+.
fitting quote from mod_ssl.h:
/* ``The Apache Group: a collection
of talented individuals who are
trying to perfect the art of
never finishing something.''
-- Rob Hartill */
Re: zlib inclusion and mod_gz(ip) recap
Posted by Ryan Bloom <rb...@covalent.net>.
> > Ryan himself said he prefers 3 right off the bat when Jerry
> > said 'Let's dump Ian's mod_gz into the core!' which is what
> > started this whole entire thread.
>
> Ask him what he thinks now :-) Knowing Ryan, he is probably fine with
> adding it at this point.
Nope. My opinion hasn't changed. I won't veto, but I continue to think
this is a bad idea.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: zlib inclusion and mod_gz(ip) recap
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 05, 2001 at 03:56:32AM -0400, TOKILEY@aol.com wrote:
> Greg Stein wrote...
>...
> > As stated elsewhere, pcre and expat are in there because they aren't
> > typically available, like zlib is.
>
> Ah... so that's the criteria? Ok.
Generally, yes. But size matters :-) OpenSSL 0.9.6 isn't commonly
installed, but it is too big for us to include. (not to mention the general
crypto issues)
> I believe the other libs you mention have been 'tweaked'
> and that's another reason why the source is there, yes?
We try to avoid it. Speaking for Expat, any differnces from Expat's CVS is
simply because I haven't done the cross-patching needed yet.
> What if you ever need to 'tweak' ZLIB because it was never
> really designed to be a real-time data compression engine?
> Would that remove the 'no ZLIB source' dictum?
It certainly could, yes.
> > Nothing needs to happen, so it shouldn't be surprising :-). If/when we need
> > it, then we will include it. As I said, it is just config macros.
>
> You are putting an awful lot of faith in ZLIB and the assumption that it
> will suit your needs 'out of the box' but I hear ya...
Until I learn differently, I'll trust that all the other zillions of zlib
users have ironed out the problems. At this point, I have no concrete
evidence that problems exist in zlib; just some FUD :-)
> > There are three options on the table:
> >
> > 1) include mod_gzip
> > 2) include mod_gz
> > 3) include neither
> >
> > I believe there is consensus that (3) is not an option.
>
> Huh?
>
> I didn't see any real consensus on that.
> Only a real vote will tell you that.
We don't always need votes to get a general feeling of people's thoughts on
various issues.
> Why note call for one?... not a vote on any particular piece of code
Because we don't need to. General consensus is supportive. We'll continue on
the assumption that *something* will go in, until somebody actually gets up
and vetoes it. But that probably wouldn't happen until we've selected mod_gz
or mod_gzip for what goes into Apache.
>...
> Ryan himself said he prefers 3 right off the bat when Jerry
> said 'Let's dump Ian's mod_gz into the core!' which is what
> started this whole entire thread.
Ask him what he thinks now :-) Knowing Ryan, he is probably fine with
adding it at this point.
>...
> No one ( including myself ) has made any kind of airtight case
There is very little that goes into Apache nowadays that has an airtight
case. A general feeling of consensus implies we don't need it.
>...
> > Despite yours and
> > Peters pushing and stressing and overbearing "sell job" to get mod_gz(ip)
> > type functionality into the core, it was just preaching to the choir. (well,
> > okay: maybe Ryan didn't want to see it in there :-) That sell job mostly
> > served to create an air of hostility.
>
> Yea... okay... whatever... we are the 'bad guys' again for trying to
> improve your Server. Mea Culpa.
Now you're just misconstruing what I said. I talked about your *approach*.
Your intent/hope to improve Apache is welcome and appreciated. But you
consistently aggravate people with how you approach and handle discussions.
>...
> > But then you say to look at the 1.3 version.
>
> What I meant was... if anyone wants to see right away if a whole bunch
> of pure 'coding style' bullshit is going to be the show stopper right off the
Coding style is never a showstopper. When it goes it, we will make it fit
the Apache coding style. Just ask Ben Laurie what some of his contributions
look like now :-)
Yes, people have complained about stuff in mod_gzip 1.x, but don't
misinterpret that as a flat out veto.
> bat then there's no need to wait for anything. As I have said 3 times now...
> it doesn't take rocket scientist to look at an existing module and imagine
> what it will STILL look like with filtering calls in it.
Of course. But people want to see mod_gzip 2.0, not the old one.
> I assure you... I did not rewrite the 1.3.x module just for 2.0. All I did
> was add the filtering calls. It was no big deal.
The post the fucker already. Just what is your problem with posting it? If
you want us to integrate it, then why not post it NOW? Please explain.
>...
> I also haven't gotten an answer to my question regarding the weird comment
> that appeared in this discussion about any module being submitted that
> supports both 1.3.x AND 2.0 in the same code ( which the mod_gzip I have
> here certainly does ) will be rejected for that reason alone.
As with the coding style, you are conflating acceptance of a module with
things that people will want to see changed. Just because people want
changes to be made doesn't mean they are flat out reject the *entire*
module.
When it goes into source control, people will:
* adjust the coding style to match Apache
* possibly strip unnecessary debug stuff
* strip out Apache 1.3 support since the code resides in the 2.0 repository
>...
> If so... then this is all a moot point. I don't have the time at the moment
> to hack up a perfectly fine module that supports ALL versions of Apache
> into something that ONLY cares about Apache 2.0. I am not even
> sure I would... it seems like a really stupid thing to do.
Nobody is asking you to. We're just asking that you post the module.
>...
> > So the inclusion of either is blocked on seeing the source to mod_gzip for
> > Apache 2.0.
>
> Not really...
>
> The vote about mod_gz was still in progress.
And it was stopped. Simple as that.
> It was about to 'pass', I think. Why not start it over again and
> see if it actually does?
As I said before: people want to constrast/compare mod_gz against mod_gzip.
> Maybe a legal majority doesn't give a crap about seeing any
> other code and would rather see Ian's mod_gz drop in the core right now.
> Majority rules here, right?
Not always. In most cases, a majority rules, but the veto is absolute.
>...
> Finding any/all remaining problems with the filtering itself should be
> the real priority in this ALPHA stage, yes?
People work on what they will. Some people want to work on a gzip filter.
Some people want to work on stabilizing the server. To each their own. If
the "stabilizers" view the addition of mod_gz(ip) as destabilizing the
server, they might veto its introduction. But a new module really won't do
that, so each group can play in their areas without concern for the other.
> > Now: you state that you don't want to release it until we hit beta. But
> that
> > is not how we work, and you should know that by now.
>
> Sorry... I must have missed that part of the Apache developer's guide.
> That is most certainly NOT how I thought you worked.
>
> I thought the idea of adding new modules in the 11th hour before a
> beta when you are still diagnosing I/O issues and/or multithreading
> issues would have historically been a real downer for you guys.
See above (what people work on).
Also: beta happens when it happens. If the server isn't stable now, then it
will be later. If not then, then sometime after that. Sure, people are
impatient, but they only have a limited control over what other people can
do to the codebase. And they certainly cannot say how people "should" spend
their time.
> > We want the module in there now, *before* beta hits.
>
> Then fer chrissakes just drop Ian's demo in. It can be replaced
> later if you find something better. You've done it before.
Again: we want to compare/contrast to mod_gzip 2.0. And replacing modules is
*not* easy. I haven't seen it happen yet.
> > You say that you don't want to release it
> > while the APIs are in flux -- that they should be stable. But that is bogus.
> > If we include mod_gzip *today*, then it will get fixed along with everything
> > else as we change the APIs. You aren't going to be responsible for keeping
> > it up to date with the changes. We are. That is part of what going into the
> > core means -- that we have an obligation and responsibility to maintain it.
> > And we will. If it goes in.
>
> Okay... now you are blowing my mind.
>
> Whenever we have tried to submit ANYTHING to you guys before all we got was
> the direct opposite. If someone submitted a module in the next hour that
> was the greatest thing since sliced bread but said 'I expect you to take this
> as-is and not bother me anymore' you would normally just say 'yea... right...
> get
> outta town'.
You misunderstand. I have confidence that mod_gzip, if you ever post the
damned thing, will be stable and require little work (other than the
"stylistic" things that I mentioned above, which people may want to do).
> You seem to be missing something here, Greg. If WE submit anything to
> Apache and it is accepted then WE certainly plan on helping to maintain
> it. If we feel ( as a company ) that we don't have the time to do so then
> it's never going to darken your door. That's the way it is and the way I
> have always understood the Apache (module) submission process to be.
When I said "we", I meant the people on this list. That includes you, but it
also includes the committers. If a committer changes an API, then it is
incumbent upon them to reflect that change throughout the codebase. In that
respect, they are assisting with the mod_gzip maintenance.
If there were no committers interested in maintaining mod_gzip, then yes:
you're right. It wouldn't ever go in, period. But I don't see that
happening.
[ altho some people are leery of maintaining a module with such a high
linecount, but I suspect a few are saying that without even seeing the
source code. ]
>...
> > * you should release your 2.0 mod_gzip so that everybody can make an
> > informed decision about putting compression functionality into Apache
>
> Agreed. It's the timing that is the only issue.
Explain why.
> > * if mod_gzip goes in, then it would do so earlier rather than later, and
> we
> > will deal with any API changes that occur between now and ship -- it
> isn't
> > your burden to bear, so there shouldn't be a reason to withold.
>
> We wanted a GA before we got involved with 2.0. That just makes
> good business sense. Looks like that's still a LOOONG way off.
I don't see how contributing mod_gzip 2.0 is related to your business. It
becomes the ASF's business once it goes into source control under our
copyright and license notice.
What I just plain don't understand at all is your reluctance to post the
source code to mod_gzip 2.0. Worse, you use it as a lever to say that mod_gz
is full of problems, yet it is a "secret" lever so your comments just appear
to be FUD.
Why not post the code? If you want mod_gzip in Apache, then post it. If
there is no way you're going to post it, then why this thread? Why are you
spending so much time with this?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: zlib inclusion and mod_gz(ip) recap
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
TOKILEY@aol.com wrote:
>
> > Despite yours and Peters pushing and stressing and
> > overbearing "sell job" to get mod_gz(ip)
> > type functionality into the core, it was just
> > preaching to the choir. (well, okay: maybe Ryan
> > didn't want to see it in there :-) That sell job mostly
> > served to create an air of hostility.
>
> Yea... okay... whatever... we are the 'bad guys' again for
> trying to improve your Server. Mea Culpa.
And your motives are entirely altruistic? Why do I have
problems with that? See, if you were going about this right
it would not be RC versus AG, it would be 'us'.
> > So the inclusion of either is blocked on seeing the
> > source to mod_gzip for Apache 2.0.
>
> Not really...
>
> The vote about mod_gz was still in progress.
The issues need not be serialised, and in fact probably should
not be.
> Sorry... I must have missed that part of the Apache
> developer's guide. That is most certainly NOT how I
> thought you worked.
And yet Peter just wrote that RC *does* understand how the
AG works. I suspect it would be more accurate to say that
RC *thinks* it knows -- or else we would not have so many
disconnects like this.
> > If we include mod_gzip *today*, then it will get
> > fixed along with everything else as we change the
> > APIs. You aren't going to be responsible for keeping
> > it up to date with the changes. We are. That is part
> > of what going into the core means -- that we have an
> > obligation and responsibility to maintain it. And we
> > will. If it goes in.
>
> Okay... now you are blowing my mind.
>
> Whenever we have tried to submit ANYTHING to you guys
> before all we got was the direct opposite. If someone
> submitted a module in the next hour that was the greatest
> thing since sliced bread but said 'I expect you to take this
> as-is and not bother me anymore' you would normally just
> say 'yea... right... get outta town'.
I cannot be sure, but I think Greg was unclear. Historically,
modules have been added to the core either because they were
simple and any of us could maintain them sans perspiration,
or else the primary author committed to stay with us on this
list and work issues, at least until other people were up to
speed with it. mod_rewrite and mod_dav followed this latter
path, for instance.
So I think when Greg says 'us' he was assuming ongoing participation
from *you* on this list, and maintenance of the module.
But I could be wrong.
> You seem to be missing something here, Greg. If WE submit
> anything to Apache and it is accepted then WE certainly
> plan on helping to maintain it.
That meets the criteria above. :-)
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"