httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Mon, 02 Oct 2000 23:13:08 GMT
On Mon, 2 Oct 2000, Fielding, Roy wrote:

> Yes, I suspect it will need to be "done" by the core filter
> (or, to use a better term for it, the message envelope filter)
> since that is where chunks need to be coalesced as well.  It
> was my impression that Bill's filter would be placed by the
> core filter and not by other filters, given that it is static
> to http_protocol.c.  That is equivalent to buffering within
> the core filter.

Being a static function doesn't mean it must be placed by the core
filter.  As long as the function can be named at some point, it can be
added by anybody.  This is why I want this as a part of the core
filter.  Doing the buffering in multiple places, or anyplace other than
the core filter is a bit bogus.

> Regardless, we used to have a general rule that a veto is only
> applicable if the vetoed solution is believed (by the veto wielder)
> to be worse than the current distribution package (this was pre-cvs).
> I'd rather encourage people to commit better solutions than to sit
> around and argue about what has already been committed, even if it
> isn't ideal.  Now that we have added filtering code to 2.0, arguments
> about design purity must take a take a back seat to getting the code
> working in an acceptable manner.  Otherwise we'll never learn
> from real experience.

I can whole-heartedly agree to that rule.  I would much rather see us move
forward in small steps than argueing over the correct approach.

> BTW, this will only work if we prevent ourselves from considering
> the existing code to be sacred.  IMO, anything within the existing 2.0a
> server can and should be replaced by any solution that does "better",
> with the exception that we have to keep compatibility in mind
> whenever a config file is changed.  That way, we only have to argue
> about what "better" means, and not what "pure" means. ;-)


++1.  Except my code, that is sacred, right.   :-)

Ryan

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


Mime
View raw message