(a simple diversion I hope from the other thread; I'll get back to that as soon as practical, and I appreciate the contributions there)
We're getting pretty late in the 2009.06 cycle, so big changes for Apache configuration aren't likely to be introduced until post-2009.06 development builds begin. I think we should consider attacking one aspect of the existing configs in the very short term: extraordinary virtual memory use. Our basic philosophy is that installed features should be immediately consumable with no additional configuration. As an example, simply installing Apache and PHP allows you to plop a PHP application in a reasonable location on the filesystem and it just works, because of the default configuration which is delivered. You don't have to know much at all about Apache and PHP, and you can quickly get a real application running. Some of the default Apache configuration doesn't provide such immediate value. Here are just a few examples, all of which do nothing but consume memory and limited CPU cycles until you change the Apache configuration: mem_cache and disk_cache are loaded by default, but * the vast majority of Apache configurations don't use either * those that do almost always use only one of them (and mem_cache is relatively unloved) * anybody who can figure out their configuration will have no problems uncommenting out the necessary LoadModule directives all the proxy modules are loaded by default, but * most Apache configurations don't use any of it * some of the protocol modules, such as connect and ftp, are used very rarely * figuring out which LoadModule directives to uncomment isn't difficult ** they'll quickly determine that they need to enable mod_proxy.so, and commentary in the config file next to that directive could explain when the others are needed, as the error messages for missing protocol support require a search engine for interpretation IIRC all the authn/authz modules are loaded by default, but * some of the database-specific modules are almost never used * when Apache auth other than host-based is used, usually only one of the database-specific authn and corresponding authz modules is used * host-based is commonly used, and some of the modules for the authn/authz infrastructure are error prone to determine so they should remain loaded by default, but the database-specific modules are relatively easy for a user to determine (the directives you add are specific to those modules) (more examples upon request) Any concerns/objections, or comments on the practicality of getting this changed in time for 2009.06? One obvious concern is during an OpenSolaris upgrade. I don't know what happens with conf files during that operation. If a user has to manually maintain their own httpd.conf (where they may have added directives which utilize some of these modules) then they also have to to preserve their modules-32.load/modules-64.load, even if they didn't modify it; if a modified httpd.conf would be retained automatically but an unmodified modules-nn.load would not, then their configuration could be broken.
