On Thu, Dec 3, 2015 at 10:32 AM, Nick Kew <n...@apache.org> wrote: > On Thu, 3 Dec 2015 10:09:08 -0600 > William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > Most stock/core implementations shouldn't > > change if a user wants to plug in 'yet another' option, but there is > > really no excuse for us to map so many ldobjects and text pages into > > the memory map of a given process, when the actual program text page > > of each is a few hundred opcodes, max. > > Extensibility. Flexibility. > > They're our biggest single strength when compared to > the likes of nginx/tengine. >
Yup, and I'm not proposing to eliminate the mechanism, I'm proposing that the existing 'core' subset be codified in fewer, still lightweight modules. > > (You can submit that the user could want to replace the bytraffic > > implementation, for example, but I'd counter that they can certainly > > rebuild any mod_lbmethod_core module with the others still using > > stock sources, and deploy their alternative, or they can give their > > custom fork of a provide yet another provider name.) > > Someone wanting different functionality shouldn't have to > take on the maintenance headache of hacking into one of > our modules. We have our API/ABI promise to make life easy > for them introducing their own modules. > If they are *replacing* our tokens, that's on them. They can add their own lbname, e.g. bytraffic-hacked, without rebuilding a core provider. And I'm not going to propose any of this for backport, in fact I don't plan to condense the source files at all, only simplify their hook registration and compile the several providers under a core module umbrella. > I'm not asking anyone to coalesce these, though. It was already > > on my rather long list of 'nice to have' along with supporting > > multiple conf mergers per module (effectively allowing 'multiple > > modules' to be a single module and splitting our monstrous core > > server and dir configs into related digestible pieces that rarely > > need to be merged, and optimizing away modules with no conf merge at > > all). And along with cleaning up the httpd 2.next API, and i18n of > > error output which I am continuing on first once the mod_ssl issues > > for mod_ftp are resolved (my current project). > > Hmmm. There's some nice-to-have in there, but it also sounds like > a big hack. > Actually they are the ideas and justifications; 1. multiple conf sections) right now, a module such as core or mod_ssl has a small subset of "key" config directives that change often, perhaps in nearly every <VirtualHost > block or <Directory > level. Then there is a majority of directives that never change from either the global or first-triggered block (e.g. toggling auth from denied to a site-wide global permitted state). These are merges that just should not have to happen on each and every merge. Directory is obviously the worst offender, while Server blocks are merged at startup and don't enjoy nearly as much optimization. Dropping any module from the merge list that has a NULL merge should speed up directory merges, too. Unsuitable for backport. 2. API cleanup) I'm looking at a util_compat.h that would map all of our long-deprecated ap_ functions into their apr_ or newer _ex equivalents. And busting up httpd.h, starting with util_strings.h Unsuitable for backport. 3. i18n) You ask about our "strengths", we have little globally until we actually internationalize error output. Most servers beat us a long time ago in this respect. Errors are more confusing than learning the few tokens you need to write a config (however, some internationalized .conf.in files for descriptive text would be a help.) The specific error lookup has can be overridden per-server, giving shared hosting providers the ability to let vhost admins grok the errors their site is receiving. It's nothing more than a hash table now that we have decorated APnnnnn throughout the 2.x and 2.4 error output, so this one can be considered for backport. 4. mod_ssl) yes, I know my last Upgrade: TLS/1.0 patch doesn't interact with the Protocols directive and h2c, since Protocols directive patch failed to pick up the existing mod_ssl Upgrade/ Connection logic. Working on that fix right now so that both options present just one unified Upgrade/Connection message. That fix aught to be backported for completeness. 5. mod_ftp) several recent mod_ssl changes busted mod_ftp's AUTH TLS support - and possibly due to my implicit HOST command hack (the result of a HOST command is the same 221 welcome as an initial connection, so this was a fakeout to cause that initial greeting - based on the SNI hostname in the case of explicit SSL.) Both the implicit port 995 and plaintext port 21 flavors were and are still working, so it is just a matter of better coupling mod_ftp AUTH TLS to the upgrade mechanisms of mod_ssl. Hopefully minimal or no core mod_ssl changes are needed. I'm looking, none of these seem like huge hacks, wondering which of them trigger your concern? Cheers, Bill