Alex Rousskov wrote:
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?
I think you are both looking at this in isolation. It is not an
all-or-nothing situation.
squid has these types of modules:
1) built by default AND enabled and working by default (HTTP, ICP, etc)
- I think these should all be built-in by default and pre-linked.
2) built by default AND disabled by default (SNMP, etc)
- I think these should be packaged as loadable modules with the main
squid binary by default.
Henriks request for --disable-module-loading implies they would be
loaded dynamically anyway, but as with now, not used unless turned on in
squid.conf.
3) require ./configure AND enabling in squid.conf
- should be left as loadable modules, not built by default, but if user
./configure'd they be built as (2).
4) future third-party modules
- would always be loaded dynamically.
People who want a plain vanilla squid will get all the modules, but
never have to worry about the loading-failed problems with the default
ones. A very slight chance of linking problems with advanced configs
using non-defaults, and their choice if they get to decide
built-in/loadable when using ./configure.
Any policy changes like turning one on or linking by default should be
made per-module at the same time as deciding whether anything is
experimental / stable / deprecated in the squid version.
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?
A bad concept comes to mind. Whats left if squid is entirely modules and
they are turned off?
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?
Means the same thing as what Henrik suggested but with less-intuitive
wording methinks.
Side thought:
This whole discussion lends itself to provide a good name for Adrians
earlier requested new directory 'modules'. As all the new modulised code
with good copyright tracks gets made into modules it goes in there.
Makes it clear its the modulised code and sticks with the naming
scheme started with /helpers/ and /tools/ and /tests/
Amos
