Aaron Stone wrote: > We dropped the dbmail_config table very early on, between DBMail 1.1 and > 1.2. There were good reasons to have a configuration file, and once things > started going in there, having two places to configure the daemons seemed > like a bad idea. One concern I remember was about the running configuration > being different from the values in the database; basically, did you > manually alter the database config values without bouncing the daemon?
Hate to break up the party, but: I'm deeply suspicious of the config table idea. It sucked back then, and I havent heard _any_ compelling reasons that would support the added complexity. Other than the lack of any perceivable added benefit (for me at least), my main objections are with regard to change management and security. For example, I like being able to stick /etc/dbmail/ into a git repository. And I *really* don't want my ldap bind_dn parameters in a database. This is a no-go area for 2.4.0 in my book. Once we start working on the hydra idea (supporting separate/different database backend servers per user) post-2.4 it might make some sense for very large deployments to alleviate management complexity. But not for the 2.4 release. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
