On Wed, 2005-02-16 at 11:05 +0000, Tony Finch wrote:
> On Wed, 16 Feb 2005, Bill Hacker wrote:
> >
> > Much as I live and breath SQL RDBMS I would vote *against* adding that sort of
> > complication to Exim core code or dependencies.
> >
> > The existing msql, pgsql, oracle, etc tools can do anything SQL'ish that makes
> > sense (and a lot that probably should not be done as well!).
>
> Nigel's aim is to simplify the multiplicity of SQL APIs that Exim has to
> know about by just using sqllite.
Not quite. I was suggesting that a sqlite lookup interfaces (which
should be trivial to build - pretty much a cut and paste job on one of
the other sql interfaces), would give you read/modify/write capability
without inventing new syntax. Sqlite would be a reasonable (in my view
- other people may have differing views on reasonableness or otherwise)
step up from the r/o key-value lookups in base exim, and putting a full
SQL server onto a box.[*]
It does, however, fly in the face of my view that we need to reduce the
number of compile time options. SQLrelay is any approach to doing that
- you make exim talk to SQLrelay and punt the thorny issue of which
database libraries you link in to SQLrelay - gaining a long running
process which can do a degree of caching and/or database process
pooling. Exim loses a ton of database specific code and linking issues,
but gains a dependency on an external package. I'd go for that trade
off, except at present SQLrelay does not appear to be a standard
component on the sort of OS/distribution we aim at.
Discussions of these thorny issues, with a mandatory pint, could be done
at the Exim Conference (that plug seems to have slipped itself in...).
[*] SQLite is a small C library that implements a self-contained,
embeddable, zero-configuration SQL database engine. [From the blurb on
http://www.sqlite.org/ - it *is* a packaged component for many
distributions, although not in the standard base list for most]
> It would not be part of the core code
> or dependencies; it would be optional like the current SQL support.
*Exactly* like current SQL support. Its just another lookup type.
The rationale is that if you are going into modifiable databases you are
only half a step from wanting a "real database" so lets go for a mini
version of a real database rather than adding Exim facilities for doing
extensions of dbm/key/value sets - leverage someone elses work rather
than do it ourselves.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
