httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey A. Stuart" <>
Subject RE: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 23:45:43 GMT
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 format)
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 a
VERY long time.  Then after about 9 months or so, they finally had to decide
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 of
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 up
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
Subject: RE: [PATCH] bucket problems.


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 your
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 filtering
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 go
through the pain of adapting their modules for the newer more stable, faster
Apache 2.0

This is just a thought. Ignoring me will cost less effort than flaming me
but you know where I am :)



-----Original Message-----
From: []On Behalf Of
Jeff Trawick
Sent: Wednesday, January 17, 2001 2:51 PM
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 mod_autoindex's
> > 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 extrapolating
> that it is the only way to do this.  I added the pass_brigade where I did
> because I wanted a working example.  A real example will actually have to
> 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 have
> multiple people with different priorities.  This is what I have currently
> 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 Apache
> 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.

Jeff Trawick | | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message