For those who might be interested. Comments welcome.

A few weeks ago I had started redesigning how Dovecot handles configuration files. I wrote a new parser and converted dovecot-auth to use the new way. Today I finally managed to convert imap process as well, which wasn't that easy because I didn't want mbox/maildir-specific settings to be hardcoded in any common code.

So, the changes will be:

• Dovecot master process will need a new completely different configuration file which tells what processes to run and their uids/chroots/memory limits. Very much like Postfix's master.cf. I'm not sure about its format yet (suggestions welcome), but maybe something like it's already:

process imap-login { executable = /usr/lib/dovecot/imap-login chroot = /var/run/dovecot/login uid = dovecot vsz_limit = 32M } ...

Hopefully after these changes the master process will become very small and simple.

• One of the processes will be a configuration process, which is the one that reads and parses the configuration for non-master processes. The default configuration file format will be pretty similar to what we have now, but it can of course be replaced with SQL backends and whatever.

Config process will listen in some unix socket waiting for requests from other processes, which connect to it just after they start up and maybe also sometimes later (eg. to get user/IP-specific settings when a new client connects).

• The data that config process sends and what other processes parse is based on simple key=value pairs, so it's possible to still store and parse them from environment if needed. Also it makes it possible to override settings from command line (eg. imap -o mail_debug=yes) or give user-specific settings in userdb. Here's an example:

config process reads something like:

mmap_disable = yes namespace foo { type = private separator = / mbox { dir = ~/mail mbox_read_locks = dotlock } }

# sends out: mmap_disable = yes namespaces = foo namespaces_foo_type = private namespaces_foo_separator = / namespaces_foo_mbox = 1 namespaces_foo_mbox_1_dir = ~/mail namespaces_foo_mbox_1_mbox_read_locks = dotlock

• Config process should verify that all given settings are valid so that typos are noticed. This may not be that easy because the setting definitions are distributed all around the source code. I think there needs to be at least a (Perl) script that finds out all the setting definitions and writes them to some all-settings.c for config process so it knows them.

Settings for plugins are more difficult though.. Should they somehow be marked in config file that they're plugins (plugin foo { .. })? Or maybe config process could dynamically load all the plugins itself and request their setting definitions?