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?
>
> A dbmail-config utility that managed this table for you would be a great
> thing, IMHO, to centralize sanity checking and bouncing of daemons, etc. A
> way to ask each daemon to report its configuration values would allow this
> utility to interrogate the running process to see if anything is different
> than what's in the database, too.
>
> Lemme see if I have the original dbmail_config table definition hanging
> around...
>
> CREATE TABLE config (
> configid int(11) DEFAULT '0' NOT NULL,
> item varchar(128) NOT NULL,
> value varchar(128) NOT NULL
> );
>
> Yeah, pretty simple key-value store. IIRC, the 'configid' was intended to
> allow multiple running configurations, but in practice was not used (I
> cannot find any code that references it). To revisit this idea, I'd suggest
> adding a 'section' and timestamps on the rows, drop the 'configid' concept
> (makes no sense; use a different database to completely separate separate
> data), and IMHO, don't bother with a row id of any kind, just put a UNIQUE
> INDEX on ('section', 'item').
>
>
If you go down that route, you might want to think about putting
hostname against each of those entries.
If somebody has multiple instances connecting to a single database, they
may well want to configure each of them differently.
(take a look at mythtv for an example of this)
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
