Summary first: I think the current configuration system is getting more
and more messier as new plugins are added, it has some shortcomings and
the possibility for a per user configuration is a good idea for many
uses.
Let me think about it step by step:
1. With every new plugin we end up with even more files in ~qpsmtpd/config.
Additional we have some common config between qmail and qpsmtpd in
/var/qmail/control.
This means that ~qpsmtpd/config is getting more and more confusing and
we run into the danger of having collissions between config files. The
solution for latter is naming the config files in a scheme like
'pluginname_file' as i have been doing it for my plugins. This would
solve the collission problem - but not the confusion.
I suggest having a ~qpsmtpd/config/<pluginname>[:x]/ directory for each
plugin in which the config files for this plugin goes. This would even
allow having different configs for different instances of the same
plugin (pluginname:0, pluginname:1, ...). This would require no changes
in the plugin, just in the config handler. If config 'sample' is required,
it could search for the file in the following order:
1. ~/qpsmtpd/config/pluginname:x/sample
(only if the calling plugin is actually a secondary instance)
2. ~/qpsmtpd/config/pluginname/sample
(for the standard module, also for a secondary instance without
different config)
3. ~/qpsmtpd/config/sample
(for compatibility, also for common configuration)
4. /var/qmail/control/sample
(same as before)
2. We have currently two types of configuration. One is in files under
~qpsmtpd/config, the other ones are parameters specified in the plugin
file. Although the latter is convenient, i think it should go away,
because a.) adds to the confusion and b.) makes per-user config more
of a problem. This change would in fact require a modification of
existing plugins, but i think in the long run this would be worth it.
3. Staying with per-user config: I would suggest having a "conf" hook,
which gets called every time a plugin requests a config file. This
would allow implementing two major improvements:
a.) Configuration actually does not need to be in files anymore. It
could be (like in my suggestion above), and a standard plugin
(conf_files) could implement that.
But this would allow one to write other config handlers, who
actually get config out of a database, by LDAP or other means.
b.) This also solves the per-user configuration problem. The conf
plugin would be told: the calling plugin, the hook in which this
plugin is running, the transaction.
Now if for example our conf plugin is called by an rcpt plugin,
it could check the recipient, and return different configuration
depending on recipient. E.g. i imagine a plugin looking up the
user in LDAP and extracting configuration for the calling plugin
from that.
(One problem: I'm not sure if the recipient would already be
available via transaction at this point. I think not, but there
sure is a solution for that problem).
4. Now the last thing to solve for per-user configuration is enabling
or disabling specific modules. I suggest solving this by simple
adding all plugins to the configuration, and before calling a
plugin making a conf-call for plugin 'x', confentry 'run'. Default
return would be 'run' (or 1 or ...), but a conf plugin could
also return 'norun' (or 0) depending on user and per-user conf.
Comments?
-kju
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
