We might be headed off the deep end, but, IMHO, it's an important exercise to
see what's out there. There are certainly some large installations of DBMail
right now, and with 2.x, even larger ones should be expected. Many of these
larger installations will have reasonably complex environments already running
and it would be best if DBMail could adapt a bit to fit.

Aaron


[EMAIL PROTECTED] said:

> Aaron Stone writes: 
> 
> for the sake of the ideas, this is getting too far and at the end it will be 
> too bloated. making everyone happy is not the most important thing here, i'm 
> happy with what i have and i'd change it the way i like it to suit me, be 
> that code/conf/whatever. what one code need is a good framework around which 
> we can hack.. and not to waste time on 'Oh, wtf is this'... 
> 
> I suppose you understand what I'm saying, sometimes a bit of abstraction
> can reduce code and efforts, but too much can cause panic .. 
> 
> dont get lost in the loop guys. 
> 
> if my ideas and suggestions will lead to more complexity, please drop them.
> i'd prefer to have dbmail the way it is now, than having it bloated with 
> those stuff below.. 
> 
> c 
> 
> > This does indeed give everyone what the want wrt config files, but also
> > introduces a lot of complexity. That's no necessarily bad, so long as the
> > simple cases are handled simply. 
> > 
> > So, if you have a current config file, with everything in it, and no 
> > database
> > config table... works fine. 
> > 
> > And, if you have a database only config file, with just the minimum needed 
> > to
> > "bootstrap" into the database config table... works fine. 
> > 
> > Then, for crazy people, crazy things are possible if you're paying attention
> > to the order of inclusions... complicated, but possible. 
> > 
> > Unless I left anything out, it sounds to me like this satisfies the "simple
> > things are simple, complicated things are possible" rule of UNIX 
> > Philosophy. 
> > 
> > I can already hear Ilja groaning about this one, so if this is the code we
> > want, someone's gonna have to do it ;-) 
> > 
> > There was one more issue, btw, which was the table names. I don't think that
> > fully configurable names are particularly necessary, but one place where we
> > might want to look into something like that is the users table. For people 
> > who
> > might already have a pam_mysql or an apache mod_auth_mysql database, it 
> > would
> > probably be nice for them to have dbmail use that existing database rather
> > than migrating the users into dbmail and reconfiguring everything else. 
> > Dunno
> > how to do this, just yet, although we should take a look at what pam_mysql 
> > and
> > mod_auth_mysql use in their config files. 
> > 
> > Aaron 
> > 
> > 
> > ""Jesse Norell"" <[EMAIL PROTECTED]> said: 
> > 
> >> 
> >>   An idea that may work to suit everyone's preference of the config
> >> layout:  define specific section names for config items, like [SMTP],
> >> and add that field to Aaron's table example below, and add an
> >> [INCLUDE "/path/to/filename"] function to the config file parser. 
> >> 
> >>   Make the config reader get the db parameters from the config file
> >> (also add an (optional) item to the config file to disable
> >> database config lookups completely for those who don't use them),
> >> read in all the default values from the db, then override with any
> >> host specific values from the db, then read through the local config
> >> file and override settings with anything found there. 
> >> 
> >>   Everyone could have the setup they wish - a huge dbmail.conf file,
> >> or a minimal one with mostly db config settings, or even break the
> >> local config into multiple files (/etc/dbmail/{dbmail,logging,host}.conf)
> >> or whatever else you could think of. 
> >> 
> >>  
> >> 
> >> ---- Original Message ----
> >> From: Eelco van Beek - IC&S <dbmail-dev@dbmail.org>
> >> To: dbmail-dev@dbmail.org
> >> Subject: Re: [Dbmail-dev] Re: table prefix
> >> Sent: Thu, 8 Jan 2004 10:34:04 +0100 
> >> 
> >> > We could also do both (config on file and in the db) and keep them in 
> >> > sync. This enables easier administration through interfaces on the DB.
> >> > 
> >> > 
> >> > On 8-jan-04, at 9:44, Mark Mackay - Orcon wrote:
> >> > 
> >> > > I really like having a local config file [much better than the old 
> >> > > days of
> >> > > having to compile the database name in, etc]; and I like being
> >> able to 
> >> > > just
> >> > > 'vi' a file to enable logging, adjust process levels on one of the 
> >> > > hosts,
> >> > > etc.
> >> > >
> >> > > If you want to do database configs as well, then the syntax below 
> >> > > would work
> >> > > -- but rather than via hostname, I'd recommend making it some form of
> >> > > 'clientid/configid' which could be supplied on command lines (e.g.
> >> > > ../dbmail-pop3d -configkey DEFAULT) That would allow configs to be
> >> > > experimented with and changed between without having to affect other 
> >> > > daemons
> >> > > on the same host, etc.
> >> > >
> >> > > Personally I just say keep the config files :)
> >> > >
> >> > > Cheers,
> >> > > Mark.
> >> > >
> >> > >> 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)
> >> > >>   )
> >> > >
> >> > > _______________________________________________
> >> > > Dbmail-dev mailing list
> >> > > Dbmail-dev@dbmail.org
> >> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >> > >
> >> > _________________________
> >> > E.J.A. van Beek
> >> > ICT Manager
> >> > IC&S
> >> > T: +31 30 6355730
> >> > F: +31 30 6355731
> >> > 
> >> > PGP-key:
> >> > www.ic-s.nl/keys/eelco.txt
> >> > 
> >> > _______________________________________________
> >> > Dbmail-dev mailing list
> >> > Dbmail-dev@dbmail.org
> >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >> > 
> >> -- End Original Message -- 
> >> 
> >> 
>  
> 
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 



-- 



Reply via email to