httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: filtering patches
Date Mon, 10 Jul 2000 23:57:29 GMT
On Mon, 10 Jul 2000, Greg Stein wrote:
> On Mon, Jul 10, 2000 at 03:56:15PM -0700, rbb@covalent.net wrote:
> >...
> > If your module doesn't use the filtering stuff, we still use BUFF.  If the
> > first two modules written do character set translation and chunked
> > encoding, then we are done.  Since the only module that currently uses the
> > filtering is the core, I don't think this is an issue.
> 
> Well, the core is the thing sending out a lot of content today. I think it
> should probably have chunking/xlate/buffering :-)
> 
> Hmm... I guess this also associated with the "modules must be rewritten to
> use output filtering" issue. Either we mandate that all content generators
> are rewritten so that we can drop BUFF (in favor of the filters), or we
> include both BUFF and the new BUFF-replacement filters in the final code
> (eek!)
> 
> [ or provide a way for today's modules to use output filtering. My patch
>   does this, but I don't see how it would be done in your patch right now.
>   It assumes all buckets (brigades) can be set aside; I'm not sure how that
>   set-aside requirement would interact with ap_rwrite and friends. or maybe
>   the requirement doesn't exist? ]

I actually could provide a way for today's modules to use output
filters.  It's actually incredibly simple.  Just make ap_r* create a
bucket and then call ap_pass_brigade.  This would take all of twenty or
thirty minutes.  I didn't do it, because I don't think it's the right
solution.

> > You are asking for a complete patch though.  This is a design and a
> > beginning to the implementation.  Yes, I could go off on my own and write
> > this code and just drop it on the list one day.  If this is what you want,
> > let me know.  I'll go away for a few weeks.
> 
> No... sorry that I gave that impression. My ideal is that your patch
> continues to use BUFF for the output rather than trying to replace it at
> this point. In other words: torch some of the code from your patch :-). That
> will allow your patches to start working a bit better right out of the gate.

No, that's the wrong solution.  People fix things when they are broken,
not when they are sub-optimal.  We commit the current patch, and in the
next two weeks, somebody will fix it.  How can I garauntee that?  Because
if nobody else steps up and volunteers, then I will.  This is important to
me, so I am not going to just drop it.  The patch is relatively small
right now.  Yes, we break some things.  So what.  This is an alpha.  We
can break whatever we want, as long as it is obvious how to fix it
correctly.  The obvious fix for these two problems, is to write a filter
that performs the required actions.  Those are small, simple filters to
write.  I don't see that as an impediment to this patch.

> In a future pass, then we can start to replace BUFF. But those patches
> will be focused on that task, rather than a combined "add filtering,
> avoid BUFF" patch.

The filters avoid BUFF as a part of the design.  Yes, they could use BUFF
at the bottom, but that would be a step backwards.  If you would like to
do this on your own tree, just make core_filter use bwritev instead of
ap_flush_to_iol.  Even if I remove that section, all I would do is make
core_filter call ap_flush_to_iol, and the day after I commit this patch, I
would change it back, because ap_flush_to_iol is the right solution.

Ryan

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


Mime
View raw message