Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Errors-To: <wrowe@rowe-clan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
Subject: RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Date: Sat, 14 Oct 2000 01:19:13 -0500
Message-ID: <000401c035a6$acde31a0$92c0b0d0@roweclan.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <m38zrsrn1e.fsf@adsl-77-241-65.rdu.bellsouth.net>
Importance: Normal

> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Saturday, October 14, 2000 12:48 AM
> To: new-httpd@apache.org
> Subject: Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
> 
> > I like the thought of being able to extend -what- filters can do, and
> > -how- they can do them.  Extending into the vast unknown future bucket
> > types seems useful in ways we can't predict yet.  I'm just making certain
> > that your performance issue is really the issue, or did we jam things up
> > somewhere else?
> 
> Nobody is speaking against such an extension; I'm definitely for it.
> What I'm speaking about is more code in the path which we don't need.

Then I need to take a close look at the code we don't expect we need... can
I read the tree or did you last proposed patch overlay the behavior you
take issue with?

I've been a c++ com programmer for years - and I know many folks look at it
as wasteful - but if you are tight (we are) you shouldn't be wasting more
that a few cpu clicks with the double indirections.  Now that I'm understanding
here what Ryan proposes - give me a little time to a close look at it before
we talk about backing it out ... I'm a little frustrated with all the talk in
the alpha of 'backing out' - we should be pushing forward and improving.