There is a need and an audience for both. We provide
both. I see no reason for us to stop doing that unless
we feel that we can no longer support both in the
manner in which our community expects. FWIW, I don't
see that as the current situation.
> On Jan 18, 2016, at 9:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski <j...@jagunet.com> wrote:
>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <j...@jagunet.com> wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@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 :)
