Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <1441CA88-2B82-4746-BA69-7A60F02CCEA5@jaguNET.com>
References: <56954235.2010707@rcbowen.com>
	<CACsi251SHdyRggdaYXSe3DwMwwoCrOgS6qoBZYT3MY+6L+hzOw@mail.gmail.com>
	<ED63EABB-1ED8-4FAD-8C26-04A83E4B2946@jaguNET.com>
	<CACsi251YKo+TUF7LLNdH5AF=kZjYhKzTCC8H9ZWkF+fPcJeFNQ@mail.gmail.com>
	<7EE0E7E6-21E7-4738-B6CA-872D79D363BF@jaguNET.com>
	<CACsi2510xygBbu-r53jX6u+04eRM0WygiCFQPERJjFvtqf6-9w@mail.gmail.com>
	<1441CA88-2B82-4746-BA69-7A60F02CCEA5@jaguNET.com>
Date: Mon, 18 Jan 2016 20:29:31 -0600
Message-ID: 
 <CACsi251zsfU82DJ5RbEF-ZcS4r8xr0XZw1XanSo6pgB+-b8yBA@mail.gmail.com>
Subject: Re: mod_fcgid and broken doc links
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a11409b98c070010529a6a318

--001a11409b98c070010529a6a318
Content-Type: text/plain; charset=UTF-8

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 :)

--001a11409b98c070010529a6a318
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 18, 2016 at 3:29 PM, Jim Jagielski <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jim@jagunet.com" target=3D"_blank">jim@jagunet.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; On Jan 18, 2016, at 3:28 PM, William A Rowe Jr &lt;<a href=3D"mailto:w=
rowe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski &lt;<a href=3D"mailto:j=
im@jagunet.com">jim@jagunet.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Jan 14, 2016, at 5:19 PM, William A Rowe Jr &lt;<a href=3D"mai=
lto:wrowe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Good point with your example, this is something that should<br>
&gt; &gt; be benchmarked and the winner-take-all, loser bumped from the<br>
&gt; &gt; trunk/ copy of httpd.<br>
&gt;<br>
&gt; -1<br>
&gt;<br>
&gt; You are implying that one would be a winner in all cases. The<br>
&gt; whole idea is that there are cases where one is better than<br>
&gt; the other. We provide both.<br>
&gt;<br>
&gt; You might have made that inference, but I&#39;m going to assert that<b=
r>
&gt; for this one module, for s/{literal}/{repl}, mod_sed is going to<br>
&gt; outperform mod_substitute /if/ we wrote the code correctly.<br>
<br>
</span>I disagree... it&#39;s kind of obvious by simple inspection that<br>
mod_substitute has fast paths that mod_sed lacks and, as thus,<br>
can be quite performant and the &quot;better&quot; choice in numerous cases=
<br>
where that fast path is used.<br></blockquote><div><br></div><div>Well, onl=
y benchmarking is going to prove that one way or the other,</div><div>somet=
hing I don&#39;t have free cycles for right now (committed to way too</div>=
<div>many other project priorities.) =C2=A0And it perhaps opens up opportun=
ities</div><div>to optimize mod_sed in ways that might have been initially =
overlooked</div><div>when the code was thrown into trunk ;-)</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
Me, I don&#39;t tend to think of myself as &quot;smarter&quot; than all of<=
br>
our users, nor do I try to act as Big Brother and remove choices<br>
from people in cases and situations where they are using them.<br>
The ASF itself doesn&#39;t do that, nor do projects... so it seems<br>
kinda weird that you would want the httpd project to all of<br>
a sudden start removing choice and options for end users instead<br>
of helping them out and trusting them to know which impl is<br>
best for them.<br></blockquote><div><br></div><div>Thankfully, we aren&#39;=
t, but our users do look at us as experts in the</div><div>code they consum=
e, considering that we collectively have authored</div><div>and maintain th=
e stuff.=C2=A0 So they do look to us to make the best</div><div>choices the=
y don&#39;t have the individual time to compare and elect.</div><div>Why wo=
uld I want us to collectively (and for me specifically) to</div><div>propos=
e the best solutions to the common use cases, and to</div><div>depreciate l=
ess maintained code in favor of maintained code? =C2=A0</div><div><br></div=
><div>Can&#39;t imagine why I or other project members would be possessed=
=C2=A0</div><div>to do that.=C2=A0 If you figure it out, please share :)</d=
iv><div><br></div></div></div></div>

--001a11409b98c070010529a6a318--