httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: mod_fcgid and broken doc links
Date Tue, 19 Jan 2016 02:29:31 GMT
On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski <jim@jagunet.com> wrote:

>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <jim@jagunet.com> wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
> > >
> > > Good point with your example, this is something that should
> > > be benchmarked and the winner-take-all, loser bumped from the
> > > trunk/ copy of httpd.
> >
> > -1
> >
> > You are implying that one would be a winner in all cases. The
> > whole idea is that there are cases where one is better than
> > the other. We provide both.
> >
> > You might have made that inference, but I'm going to assert that
> > for this one module, for s/{literal}/{repl}, mod_sed is going to
> > outperform mod_substitute /if/ we wrote the code correctly.
>
> I disagree... it's kind of obvious by simple inspection that
> mod_substitute has fast paths that mod_sed lacks and, as thus,
> can be quite performant and the "better" choice in numerous cases
> where that fast path is used.
>

Well, only benchmarking is going to prove that one way or the other,
something I don't have free cycles for right now (committed to way too
many other project priorities.)  And it perhaps opens up opportunities
to optimize mod_sed in ways that might have been initially overlooked
when the code was thrown into trunk ;-)


> Me, I don't tend to think of myself as "smarter" than all of
> our users, nor do I try to act as Big Brother and remove choices
> from people in cases and situations where they are using them.
> The ASF itself doesn't do that, nor do projects... so it seems
> kinda weird that you would want the httpd project to all of
> a sudden start removing choice and options for end users instead
> of helping them out and trusting them to know which impl is
> best for them.
>

Thankfully, we aren't, but our users do look at us as experts in the
code they consume, considering that we collectively have authored
and maintain the stuff.  So they do look to us to make the best
choices they don't have the individual time to compare and elect.
Why would I want us to collectively (and for me specifically) to
propose the best solutions to the common use cases, and to
depreciate less maintained code in favor of maintained code?

Can't imagine why I or other project members would be possessed
to do that.  If you figure it out, please share :)

Mime
View raw message