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. > (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. > 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. > Last thought, you might want to share your question with users@? +1 -- Nick Kew
