I know there is an aversion to more dependencies but --- I vote for
power. I think in light of the things that people are trying to do here
that full database support is something that Exim should have. We need
to do complex things and it takes a database to do it. The up side is
that if Exim does yet something else that no other MTA does it will
increase the market share of Exim and bring in more support.
I see it as something that is inevitable - so we might was well suck it
up and plan to add it. And by "we" I mean Phil write it and I ask for
more features. ;)
Nigel Metheringham wrote:
>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.
>
>
>
--
Marc Perkel - marc@???
Spam Filter: http://www.junkemailfilter.com
My Blog: http://marc.perkel.com
My Religion: http://www.churchofreality.org
~ "If it's real - we believe in it!" ~
