On Mon, 12 Jul 1999, Nigel Metheringham wrote:
> Howabout we aim at making the easy things easy and the hard things
> possible.... but not necessarily by exactly the same mechanism....
> As it is people can do "interesting" lookups and other operations in
> any SQL database by cheating and shooting off in a perl expanded string
> construct. So that gives people enough rope to hang themselves and all
> their users. Using this you can do SQL based user quotas, logging and
> even basic lookups.
> Given that the wierd and wonderful has been dealt with in that fashion
> the SQL lookup method can then concentrate on relatively straight
> forward lookups - say single row single or multiple field select
> statements.
Makes sense to me.
Before PH devotes any time to specific DB engine hooks, I suggest that
those who'd be interested in this consider using the Perl DBI hooks, and
see how much of what is required can be acheived that way. All of it, I
suspect (and I don't count this as cheating, Nigel). I really like the
Perl view of things; especially that DBI scripts can be "ported" from
MySQL to Oracle to PostGRES to <insert DBMS here> with a single line edit,
assuming that one keeps the SQL simple.
*My* reason for being interested in SQL lookups is to have all my user
config data in one place, and to be able to operate on it automatically
using scripts which I'd write using Perl and DBI anyway; I'm less bothered
about speed than a site with Ks of aliases so I don't mind if there's a
bit of perl overhead and none-too-efficient DB connections. Currently, my
alias processing is not complex, but I foresee multi-site email based
bugtracking etc in the none too distant future.
IMHO what would REALLY be of use before anyone cuts more code would be
clear conventions on what tables / views Exim should be able to find - the
equivalent of specifying the alias file format clearly - and how any
future extensions should be structured. First, this enables those cutting
their own SQL (PERL or not) to build up a useful set of interchangeable
modules; if PH then develops functionality directly into Exim, we can plug
the "offical" Exim stuff in and have it work straight away. Second, many
sites user databases are NOT maintained by the postmaster, or even a
system admin; it should be possible to specify to the relevant DB admin in
e.g. personnel that a readonly DB view should be available to the mailhub
which simply "looks like this".
I suggest that PH's first pass SQL lookups in Exim is a "turbo alias file"
- i.e. no SQL visible in the Exim config itself, just "if you provide DB
tables that looks like this, Exim does the right thing", just like "if you
provide a text file in this aliasfile format, Exim does the right thing".
NB1 - just read Malcolm Beattie's coment on DBI; I second his warnings -
think hard before making SQL visible at this sort of level or releasing
something which will be treated as an API.
NB2 - anyone considered delivery into a DBMS (cf /var/spool/mail), while
we're here? An IMAP / Web client or something is required, I know, anyone
seen anything like this? Again, I'm thinking in terms of bug tracking.
Peter Lister P.Lister@??? PGP (RSA): 0xE4D85541
Sychron Ltd http://www.sychron.com PGP (DSS): 0xBC1D7258
1 Cambridge Terrace Voice: +44 1865 200211
Oxford OX1 1UR UK FAX: +44 1865 249666
