So trying to put together some of the ideas from the past few emails, here's
what I'm thinking:
dbmail.conf:
Is a configuration file in /etc or wherever.
- database information
- logging info
- hostname / clustering info
dbmail_conf:
Is a table in the database.
- Has detailed config info in host/key/value pairs:
CREATE TABLE dbmail_conf (
hostname VARCHAR(128) NOT NULL,
key VARCHAR(32) NOT NULL,
value TEXT NULL,
UNIQUE INDEX (hostname, key)
)
I suspect that a hostname value of '*' would be useful for basic, common
config options and for non-clustered installations.
By doing this, we provide a method for multiple hosts to connect to a common
database, retrieve host-specific configuration information, and begin
operation as a member of the cluster.
Regarding clustered operations, I've done a little bit of research, and
literally the only thing that needs to be done is to remove the auto_increment
columns from every table and to provide for a unique, or at least
statistically unique, ID number for messages.
Aaron
[EMAIL PROTECTED] said:
> Mark Mackay - Orcon writes:
>
> >> best scenario will be to have only DB settings and table
> >> names in the conf
> >> file.. and moving all the bulk like AUTO_* EFFECTIVE_* BIND into the
> >> database , there's no point for them being there, anyway
> >> without the DB
> >> dbmail* is useless, also consider the fact the dbmail-smtp
> >> doesn't even know
> >> what DEFER
> >> is (at least for postfix).(well LMTP will solve that - more
> >> abstraction!)
> >
> > Noooo! Settings like log-level, bindaddress, ports, etc need to be able to
> > be specified on a per-client basis (so via command line or config file
> > selected by daemon), not on a global scale only (although happy with
> > defaults accessible via database provided they can be overridden by a local
> > config).
>
> right. well that could be solved by having prefixes and still end up with
> %{DB,SMTP,POP,IMAP}_TRACE_LEVEL=%d
>
> same for having a multihomed box. (well in both case you have to hack
> dbmail.h to get it to use different pathnames)
>
> and when you have 2 different hosts accessing the same db
> dbmail1:x.x.x.x -> conftable=xxxx_conf
> dbmail2:y.y.y.y -> conftable=yyyy_conf
> and myprefix_users, etc
>
> and i'm sure you can think of many other ways how you can utilize
> abstract tablenames & prefixes ..
>
> hope my point is a bit clearer now.
>
> cheers
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
