[Dovecot] Config rewrite for v1.3

[Timo Sirainen]

Still broken, but I committed the current changes to
http://hg.dovecot.org/dovecot-config-rewrite/

The idea is something like:

 - src/config/ contains a doveconf binary which can be used to dump the
current configuration. It's the only binary that reads dovecot.conf
directly. Currently the code is kind of ugly because I wanted it to be
able to parse the existing v1.2 dovecot.conf which required some
kludging around. Perhaps in v2.0 the dovecot.conf could have larger
changes and these kludges could be removed.

 - master currently executes doveconf 3 times: for default settings, for
imap settings, for pop3 settings. The result is saved into an array of
KEY=value pairs in an array. Eventually they're still sent to child
processes via environment. This sending via environment is again mainly
for backwards compatibility with post-login scripts. Although they are
useful there, so I'm not sure if it should be kept that way. Although
post-login scripting doesn't really work anymore with Apple's
multiple-connections-per-mail-process code, so perhaps that needs some
rethinking in any case..

 - deliver also currently forks and executes doveconf. I hate this. But
I don't like the alternative of having a libconfig that deliver could
use to read the configuration inside the binary as is done now, because
then it's not as easy anymore to update the doveconf binary (or replace
it entirely). But I'm thinking about making doveconf a long running
process and deliver could ask configuration from it via UNIX socket if
it's running and fallback to forking doveconf.

The last possibility would be not to fork, but instead just have
doveconf exec() deliver, so either something like "doveconf -e deliver
-deliver-params" or if calling deliver directly it could exec() doveconf
which would then exec() deliver back. Hmm. Perhaps this is actually
better than forking?

 - %variable expansion is somewhat broken with imap/pop3, but works with
deliver. The annoying thing about this is that %vars from doveconf
should be expanded, but if userdb returns anything containing %vars they
shouldn't be (because e.g. home directory could contain %).

So either master should expand everything internally or it should
somehow tell child processes about what to expand and what not. It can't
really expand everything because it doesn't know all the settings that
should be expanded. So that only leaves the possibility of telling child
process what to expand.

One possibility is to prefix each environment with e.g. 0 or 1
specifying if it should be expanded. This would break all existing
postlogin scripts and in general would make it kind of ugly. Another
possibility would be to have an environment that lists the settings that
shouldn't be expanded. Perhaps that would work better, although if
postlogin script changes/adds environments they'd also potentially have
to modify that environment too.

 - Plugins will probably have to keep using something similar to
getenv() to get their settings. It would be possible to have them use
the nice new pre-filled settings structures, but that would require
configuration changes. For example instead of quota=.. quota2=.. you'd
have two quota {} blocks. Probably better to leave that change to v2.0.

 - I'm not entirely sure where all the setting verifications should go.
Having them done by master when starting up is nice because it can give
error messages immediately and write them to screen, instead of having
to look them up from the log. Or when reloading configuration it can
cancel it if the new configuration isn't ok. Maybe doveconf could do the
checks. Maybe the verifications could go to all the different
*settings.c files where they logically belong to, and then the build
scripts would copy those functions to doveconf code where it could check
all of them when the config is being read. The only annoying thing is
that this then required doveconf to be run as root so that it can do all
the access() etc. checks. But maybe that's not too bad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20090127/72fbdd83/attachment-0001.bin