I agree -- I think storage of configs in the database(s) is still a good
idea but with the caveats that Paul mentions...
The problem is that table and column names are all hardcoded in dbmail.
This is especially a problem with MySQL, where views don't exist, but
it's a huge inflexibility under any platform and also prevents
additional pluggable backends in the future. The dbmail conf file needs
to have user-editable locations. This is where you could have multiple
config tables or columns to configure different front ends, all storing
data in the database. This eliminates both problems at once.
PureFTPd has a good idea, for example in their conf file. You configure
your individual SELECT statements, and the default conf file could leave
them at defaults.
I.e., something like:
dbmail.conf:
config_host: x001
config_db: frontend1
config_user: frontend1
config_pw: secret
Then, in the database table frontend1, you maybe have columns or records
that hold the following:
get_message_header: SELECT header FROM data_table1 WHERE message_idnr='%L'
and %L is a variable that the dbmail daemon replaces with the current
message idnr before making the query.
For speed, all of the SELECT statements would get read into memory at
startup and reread every ten minutes. This would allow on-the-fly table
changes without starting the daemon.
Anyway, just some thoughts..
This scheme would also allow "rolling" upgrades, where you prep your new
table(s) and then (at the last minute) change your selects to point to
the new table. It'd be very nice for testing and migration purposes.
Doug Stanley wrote:
Oh...i getcha...
Hmm....perhaps the config file can list the db connection info
plus a table for each front end? I dunno...not like it REALLY matters
to me anyways :)
Doug
Paul J Stevens wrote:
I disagree. Think about a setup where more than one frontend connect to
a single backend.
Storage of configs in the database was how things were done pre-1.0.
Bad idea. I want to be able to tune front-end specifics on the front
end: listen at different addresses, run at different debug levels,
run more or less processes, etc.
Doug Stanley wrote:
I agree!
Doug
Matthew T. O'Connor wrote:
Personally, I think all dbmail configuration information should be
stored in
the database, the only exception being, bootstrap info required to
connect
to the database.
----- Original Message ----- From: "Jesse Norell" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, October 10, 2003 2:55 PM
Subject: [Dbmail] feature solicitation
Hello,
Would anyone be interested in customizable error messages for
dbmail bounces, etc.? Eg. have a directory /etc/dbmail/ with
some message templates that are used to build the actual errors
(mailbox full, no such user, etc.). Or maybe would be nicer to
have them in a table in the database (for sites that use multiple
dbmail boxes for the same message store). I'll log a feature
request as a reminder if it seems like a good idea.
jn
--
Jesse Norell
jesse (at) kci.net
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
