On Fri, 2007-10-12 at 16:14 +0200, Henrik Nordstrom wrote: > On tor, 2007-10-11 at 19:30 -0600, Alex Rousskov wrote: > > 2) --enable-external-modules :: This option will enable support for > > modules loaded runtime, from external files. There are two reasons to > > have it: to disable experimental code and to build "secure" Squids that > > cannot be altered by loading modules. Are these reasons enough to have > > this option? > > I would make it a --disable-module-loading option..
... implying that module support will be enabled by default? OK. > > 3) --enable-builtin-modules :: This option will allow the modules to > > be preloaded at Squid executable linking time. Preloaded modules > > simplify handling of Squid binaries because there is no dependency on > > some external module file and no dangers that the external module will > > not load. Should this option be named --enable-internal-modules or > > --enable-preloaded-modules or even --with-preloaded-modules? > > All our modules should by default be builtin, with squid.conf settings > for adjusting their use. Don't see the need for this option. Interesting. Why do you think that the majority of modules are going to be built in? A built-in (a.k.a., preloaded) module Foo requires relinking Squid executable with the "-dlopen Foo.la" option, right? Do you think most users would prefer to relink (which requires Squid libraries and a linker) than simply install a module and change squid.conf? Finally, if we only have the --disable-module-loading option, would it be better to call it --disable-modules? That is, have one knob that controls whether _any_ modules (preloaded or dynamic) are supported? If --disable-modules is a bad idea (e.g., because we may call a compiled-in Squid feature a "module"), how about --disable-loadable-modules? Thank you, Alex.
