Wakko Warner said:
>> > I've been thinking for a while of patching exim so that all lookups,
>> > authenticators, routers, transports, etc are loadable modules. This
>> would
>> > make it easier to add modules to the program w/o recompiling the whole
>> > thing. Be nicer if it were written that once you -HUP the daemon,
>> it'll
>> > load the required modules depending on the runtime config file.
>>
>> Just be very careful to think about security issues. You need to be sure
>> that anything you load dynamically comes from the right place. I'm not
>> so much thinking of the daemon here, but what happens when an
>> unprivileged user runs exim.
>
> I hadn't really given it a thought as to where the modules would be, but I
> would think that looking in only 1 place would work.
>
> base path would be /usr/lib/exim and under that, you'd have a directory
> for
> routers, transports, authenticators, etc.
OK, while we're discussing architecture for Exim 6, I'd like to put in my
0.02-worth...
A plugin architecture as described by Wakko is very useful for sysdev
environments. But in a medium-scale+ production environment, in which
changes in config happen rarely and in a controlled, predictable manner,
you wouldn't want to introduce per-process overhead.
So any loadable-module scheme must come with a mechanism either to ensure
it doesn't introduce overhead for production (even if this overhead is
just scanning stuff in the config and adding references to already-loaded
modules), or a way of easily 'freezing' a defined dynamic config into a
static config for deployment.
I'm also attracted by the idea of a separate caching daemon which handles
'external' lookups - it can have its own bindings to its back-end stores
(LDAP, *SQL etc) which are independent of the Exim config, and simply
referenced as tokens from Exim.
Peter
