httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] final brigade buffering
Date Fri, 09 Feb 2001 04:42:37 GMT

> It is nicer to have it right before the patch is applied, and I'm more than
> willing to do that (therefore, my offer to code a patch to show what I
> mean). But the important part is that we are of a like mind and can agree
> that it can/should be changed in a second round.

Why is it nice to have everything done before we commit?  It is much
better to get the code in the tree, where I don't have to port everytime a
change is made.

> I'm hoping that you'll understand, rather than give in. The abstractions in
> the code are important, especially when we're basing so much of our data
> flow around them. My intent is to explain where the abstraction in the
> current patch breaks down, and offer suggestions on how to improve it. I
> feel that I'm not explaining this well, because (while it may be obvious to
> me) it hasn't been clicking into place with others. I don't know how to
> explain better, despite trying; I've offered to do the code as a way to
> demonstrate what I mean.

Greg, I do understand.  I disagree.  I have decided to agree to disagree
and to allow this to move forward.  That is very different than giving
in.  Giving in is what I did a few weeks ago when I got so sick of this
that I seriously considered leaving the group (and did for a day and a
half).  Since that time, I have discovered that I don't care enough about
this to fight anymore.  I would rather get out of the way and let the
project move forward.

> The brigade buffering portion of the patch is fine to check in as-is, if
> you're fine with changing it in a second step. If you want to do it
> beforehand, then fine.

I will fix it and commit later tonight.

> I have an issue with the ap_r* implementation in the patch. I believe we can
> solve the problem without r->bb, thus avoiding ordering problems or
> requirements that people always use r->bb. I'd ask that you leave out that
> portion, and I can reimplement ap_r* and OLD_WRITE in terms of the new
> brigade buffering stuff.

I will commit without this portion tonight, but as I have already stated,
I am very much against this change.

> Were there any other pieces to the patch beyond that?
> [ 1) brigade buffering. 2) ap_r* revamp. 3) ap_f*. 4) header filter ]



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

View raw message