I thought the idea of providers and submodules were so that, for example, if someone only used byrequests, for example, they only needed to build and load that specific submodule and nothing else... Not seeing what issue exactly you're trying to address.
> On Dec 3, 2015, at 6:25 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > My personal wish list is that we eliminate module bloat by coalescing > > alternative "standard" implementations into a single module again in > > 2.next, and not just limited to lbmethod, but also the core socache > > and slotmem providers. 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. > > > > Not following you there... what do you mean? You mention the > lbmethods; do you mean instead of having each method be its > own module, making them all one? > > Not specific to lbmethods but yes, one mod_lbmethod_core.so provider > of the basic set of 3-4 methods that right now eat up a lot of 64kb process > page mappings for no particular benefit. The builder could even decide these > are compiled-in to the base httpd. We don't dismiss the loadable approach, > we simply decide this subset is effectively baked, and then use the loadable > lbmethod to extend yet another experimental/dynamic/evolving method, from > the ASF or third parties. > >
