httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: [PATCH] bucket problems.
Date Thu, 18 Jan 2001 02:16:19 GMT
> The filtering is in already.  The idea now is to perfect it, so that it
works well for
> people.  We will hit a beta soon, because otherwise you are correct,
> people will leave this project. Be patient, give us another couple of
> weeks to hammer this out finally.


We'll be here. Kevin has already coded a version of mod_gzip that uses the
new 2.0 filtering 'scheme' to compress ALL Server output but we are holding
off until you have the filtering code 'stable'. We need you to finalize on
the API calls.

Having just released mod_gzip we know first hand the issues you are dealing
and we constantly faced with the same stability vs. feature issue.

You have two key issues - native threading, and build the server in a
filtered model. Which ONE do you want to make stable first. Once you have
that you then have Apache 2.0 beta released. This gives positive momentum to
the project.

What comes next is feature number two which will need to include outside
module - author support. We can then release mod_gzip for Apache 2.0....
more positive momentum for the Apache Group which continues to build on a
successful Apache 2.0 code base.



-----Original Message-----
From: []
Sent: Wednesday, January 17, 2001 5:00 PM
Subject: RE: [PATCH] bucket problems.

There is one problem with this whole idea.  The filtering is in
already.  The idea now is to perfect it, so that it works well for
people.  We will hit a beta soon, because otherwise you are correct,
people will leave this project.  Be patient, give us another couple of
weeks to hammer this out finally.


On Wed, 17 Jan 2001, Jeffrey A. Stuart wrote:

> You know what, I have to agree with Peter on this.  Get apache 2.0 out. ;)
> The one thing that will KILL an open source project is "apparent" lack of
> progress.  Please note I stress the word APPARENT... Perfect example.
> Proftpd 1.2.  It has had no apparent progress since July of last year.  In
> my mind and in a number of other people that I've talked to, Proftpd is
> DEAD... Which is a shame...  it was (maybe even is) a good program but...
> And a couple of times a month, people come to me and ask about apache 2.0
> and when will it be out.  They had heard it was coming out (in beta
> Nov of last year, then, end of Dec, then ... Maybe it's time to step back
> for a second and decide what Apache 2.0 should REALLY have in it.  The KDE
> folk had to do that.  When they decided to come out with 2.0, it took them
> VERY long time.  Then after about 9 months or so, they finally had to
> to drop some features from 2.0 and release what they had.
> Now yes, you can say that there is traffic on the mailing list and if you
> REALLY want to know what's going on, get on the mailing list.  Well, most
> the people I deal with are not "techies" and don't have the time OR desire
> to read this mailing list.  That's my job. :)  (And to keep their servers
> and running.. :))  So they see no activity while I on the other hand see a
> FLURRY of activity. :)
> This of course is just my opinion.
> --
> Jeff (FurBall)
> WebOverdrive Newbie Tech Board
> -----Original Message-----
> From: Peter J. Cranstone []
> Sent: Wednesday, January 17, 2001 5:17 PM
> To:
> Subject: RE: [PATCH] bucket problems.
> Guys,
> Feel free to flame me or plain ignore me but I have a suggestion. Why not
> leave filtering out of the equation until the beta is stable. Filtering is
> going to cause issues with 1.x modules and will take time to explain to
> existing base.
> What I think you need IMHO is to get 2.0 stable with just one or two
> features. You have enough on the table to do that. Then introduce
> at a later stage. Adding the whole thing now along with all the other
> features is going to result in 1.x users avoiding the upgrade.
> Backwards compatibility to older modules is KEY until you have the new
> filtering system stable and OUT performing anything else. Then users will
> through the pain of adapting their modules for the newer more stable,
> Apache 2.0
> This is just a thought. Ignoring me will cost less effort than flaming me
> but you know where I am :)
> Regards,
> Peter
> -----Original Message-----
> From: []On Behalf Of
> Jeff Trawick
> Sent: Wednesday, January 17, 2001 2:51 PM
> To:
> Subject: Re: [PATCH] bucket problems.
> writes:
> > > I think the very idea of an API which adds to a brigade is
> > > problematic.  We want an API which handles output, sending it down the
> > > filter chain when necessary (i.e., when our x-kilobyte coalesce buffer
> > > is full).  With your API, some weirdo will create a filesystem with
> > > infinite entries in a directory, and rather than having
> > > processing of this directory limited by network I/O to the client,
> > > mod_autoindex will loop until all storage is exhausted.
> >
> > You are taking a part of the patch that was a quick hack and
> > that it is the only way to do this.  I added the pass_brigade where I
> > because I wanted a working example.  A real example will actually have
> > make this call whenever it makes sense.
> Do you mean that you would expect a module using this API to regularly
> decide whether or not to call ap_pass_brigade()?  It would be really
> nice to avoid that.  But avoiding it breaks your desire to avoid
> having an API which knows about both filters and buckets.
> > > I really think we want some changes with the coalesce property but
> > > also the flush-to-the-network-as-we-go property, rather than
> > > continually building up the brigade until the module sees fit to call
> > > ap_pass_brigade().
> >
> > If you can design/implement this, please feel free.  As I see it, we
> > multiple people with different priorities.  This is what I have
> > heard as priorities, please add any if I miss some.
> As I recall, Victor already started down this road but was shot down.
> > Don't change the ap_r* API at all
> > Good performance for ap_r* functions
> > Ability to use both ap_bucket_create and ap_r* functions in the same
> >       function
> > Ability to use network congestion to stop sending data
> > Don't allow the server to even try to use up all the memory
> >
> > You can't have all five of these.  Pick a few and design for them.
> As long as the app calls a flush routine (ap_rflush()), all five of
> these were met by Victor's patch if I recall correctly.
> > > But to do that the API needs to know about filters too (enough to call
> > > ap_pass_brigade()), so there is another parameter to
> > > ap_brigade_something().
> >
> > No, that is tying the buckets to the filters, which ties buckets to
> > basically, which is not correct IMHO.
> The app has to do extra work if this type of API doesn't handle
> buckets and filters.
> > It doesn't matter.  The biggest problem with Victor's patch is that it
> > puts the buffer in the request_rec, which means that we aren't helping
> > anybody other than Apache itself.
> As I mentioned before, macros could avoid having the core code
> know about the request_rec.
>   #define ap_rputs(s,r) \
>   ap_brigade_puts(r->field1, r->field2, x, y)
>   (or some such)
> But the key issue is whether some API knows buckets and filters.  To
> meet what I thought was the goal ("Allow apps which use the ap_r* API
> to perform reasonably"), I think we need such an API.
> Thanks,
> --
> Jeff Trawick | | PGP public key at web site:
>              Born in Roswell... married an alien...

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message