Re: configure options for loadable Squid modules

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.
Received on Fri Oct 12 2007 - 10:03:20 MDT