From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Wednesday, October 31, 2001 11:11 AM
> On Wednesday 31 October 2001 09:04 am, Justin Erenkrantz wrote: > > On Wed, Oct 31, 2001 at 10:49:33AM -0600, William A. Rowe, Jr. wrote: > > > OTOH, this doesn't work for static builds of mod_ssl.c, since the user > > > can't unload modules from Apache 2.0 and re-add in the same way as 1.3 > > > did. So we may wish to provide a mechansm for them to cripple ssl > > > convenienly. > > > > Hmm, sounds like we should have a syntax that says, "Static module foo > > go away. I don't like you anymore." Can't be too hard, can it? =) > > Actually, it might be... > > No it's easy, but it requires adding back ClearModuleList and AddModule, which > is just a mess IMHO. Revision 1.104 / (download) - annotate - [select for diffs] , Sun Jan 21 22:14:16 2001 UTC (9 months, 1 week ago) by rbb Branch: MAIN Changes since 1.103: +0 -18 lines Diff to previous 1.103 (colored) Remove AddModule and ClearModuleList. Neither directive really makes much sense anymore, since we use the hooks to order modules correctly. This also removes the possability that one module will ever register the same function for the same hook twice. I'm thinking this was the wrong way to go. Let's consider Win32 or any other create-process oriented server model. If the user compiles in a bunch of modules for speed (to avoid per-process resolution of each .dll/.so linkage) so their individual server processes start up quickly (e.g. MaxRequests is set to 10000 or so for some mod_perl leakage) but they don't want one of the pre-compiled modules, we are jammed. I understand the desire to set up each module individually under unix, but this doesn't work for a Win32 binary very well. A slick solution might be RemoveModule, which would simply drop one undesireable module from the precompiled modules list before we invoked the second pass through the config. If modules postponed hook registration until the second init pass, the other cited problem goes away. Does that make sense? > Just add startssl to apachectl, which adds the -DSSL, same way we do > with Apache 1.3. We have to support startssl anyway, because there are > going to be a lot of admins with scripts that rely on it. Why are we trying > to re-invent the wheel here? Sounds like the way to go, +1. Bill
