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: <20151204161722.3b753797@bifrost.webthing.com>
References: <288293CD-6D82-42E0-BFC9-9DC25F969ED6@jaguNET.com>
	<CACsi250e5arsm+EzN1KDJMOD-vAmTyM8M0utTuEfedUGSUfXJw@mail.gmail.com>
	<20151203163227.64a94c9d@bifrost.webthing.com>
	<CACsi2538wJ=w99Emp86rfC-pJC6GF4J6wUPsqQi0vT8prnd4DA@mail.gmail.com>
	<20151204161722.3b753797@bifrost.webthing.com>
Date: Fri, 4 Dec 2015 10:40:42 -0600
Message-ID: 
 <CACsi253zTyJ8KWDy3erhAvDcyS8cK-LGL=q9W2gB8nDRMcrBRQ@mail.gmail.com>
Subject: Re: reverse proxy wishlist
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2eb5a17eb740526152bb9

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

On Fri, Dec 4, 2015 at 10:17 AM, Nick Kew <nick@webthing.com> wrote:

>
> > I'm looking, none of these seem like huge hacks, wondering
> > which of them trigger your concern?
>
> Well, your talk of refactoring config led me to wonder
> whether you were proposing another tilt at the whole directory
> walk stuff.  While that may have merit, past experience
> tells us it's not going to be easy!
>

If I never have to refactor that code again, it will still be too soon :-/

More likely that someone enthusiastic could take the base/short
unique <Directory> blocks and pre-merge those to global/vhost
scope, as the shortcut to a more specific scope as the first-match
hit.  Deeper pre-merge optimizations would be rough and all of it
presupposes there are no request-specific eval blocks and no
directory permitting an .htaccess could be optimized that way.

So... no... much like the non-iterating fnmatch implementation, I'd
prefer to let others wrap their heads around that puzzle and come
up with something new and more efficient.  All I was thinking of
doing was extending the core concept of 'compiled in modules'
to allow a module-of-modules, and build unique create/merge
call tables at the end of register_hooks, instead of the slightly
odd way we we presume that each module does or does not have
one of each such creater/merger, skipping along the NULL refs.

When we last tried to optimize this, hooks were attempted and
proved to have much too much overhead. A startup-time straight
array of function pointer/conf index pointer elements will be
the only way to keep the logic as efficient as it is today, and
then build upon that model.  I don't expect we will allow the
create/merge table to change after the register_hooks phase.

--001a11c2eb5a17eb740526152bb9
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 F=
ri, Dec 4, 2015 at 10:17 AM, Nick Kew <span dir=3D"ltr">&lt;<a href=3D"mail=
to:nick@webthing.com" target=3D"_blank">nick@webthing.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; I&#39;m looking, none of these seem like huge hacks, wondering<br>
&gt; which of them trigger your concern?<br>
<br>
</span>Well, your talk of refactoring config led me to wonder<br>
whether you were proposing another tilt at the whole directory<br>
walk stuff.=C2=A0 While that may have merit, past experience<br>
tells us it&#39;s not going to be easy!<br></blockquote><div><br></div><div=
>If I never have to refactor that code again, it will still be too soon :-/=
</div><div><br></div><div>More likely that someone enthusiastic could take =
the base/short</div><div>unique &lt;Directory&gt; blocks and pre-merge thos=
e to global/vhost</div><div>scope, as the shortcut to a more specific scope=
 as the first-match=C2=A0</div><div>hit.=C2=A0 Deeper pre-merge optimizatio=
ns would be rough and all of it</div><div>presupposes there are no request-=
specific eval blocks and no</div><div>directory permitting an .htaccess cou=
ld be optimized that way.</div><div><br></div><div>So... no... much like th=
e non-iterating fnmatch implementation, I&#39;d</div><div>prefer to let oth=
ers wrap their heads around that puzzle and come</div><div>up with somethin=
g new and more efficient.=C2=A0 All I was thinking of</div><div>doing was e=
xtending the core concept of &#39;compiled in modules&#39;</div><div>to all=
ow a module-of-modules, and build unique create/merge</div><div>call tables=
 at the end of register_hooks, instead of the slightly</div><div>odd way we=
 we presume that each module does or does not have</div><div>one of each su=
ch creater/merger, skipping along the NULL refs.</div><div><br></div><div>W=
hen we last tried to optimize this, hooks were attempted and</div><div>prov=
ed to have much too much overhead. A startup-time straight=C2=A0</div><div>=
array of function pointer/conf index pointer elements will be</div><div>the=
 only way to keep the logic as efficient as it is today, and=C2=A0</div><di=
v>then build upon that model.=C2=A0 I don&#39;t expect we will allow the</d=
iv><div>create/merge table to change after the register_hooks phase.</div><=
div><br></div><div><br></div></div></div></div>

--001a11c2eb5a17eb740526152bb9--