httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: my ideal resolution to small writes
Date Tue, 23 Jan 2001 14:53:15 GMT

> In fact, the first thing I would do if I had the time would be to
> toss out every decision made at the "filters meeting" and
> reimplement the filters as a simple linked-list stack with statically
> allocated buckets (pointing to separately allocated bucket data).
> 
> I bet that would be popular.

It sure would be.  I have already tried it once.  The problem is that we
want to use pool cleanups to clean up the brigade.  I couldn't make this
work without leaving a gaping hole that would allow module writers to
easily create very significant memory leaks.  I would be interested in
seeing your approach.

> But, lacking the time, I'd settle for a 2.0 that works.
> Both of the proposed solutions are band-aids at best, so just
> commit whatever is better than today's HEAD and replace it later
> if it turns out to suck as well.  Commit both if that is what
> it takes.

In what sense are both solutions band-aids?  I would like an honest
opinion here.  Granted, this solution could be solved with a cleaner
set-aside function, but isn't that just a different band-aid?

> And I'd honestly appreciate it if people would stop making grandiose
> claims about freezing the API for some or such release.  The API
> isn't going to be frozen until it is proven to be stable, which
> means when the pressure to change it becomes less than the pressure
> to keep it static.  Just generate the bloody tarball and we can
> decide afterwords whether or not it is good enough to be frozen.

I don't believe I ever said anything about the API being frozen.  In fact,
we have made more sweeping API changes in the last week than I can
remember making any other time.  What I have asked for, is a feature
freeze.  We, I am as guilty as anybody, have been adding features to this
thing for years, and now we need to stop adding features and start fixing
the ones we have.  I see those two things as being VERY different beasts.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message