Marc Perkel wrote:
> 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.
Please identify the Exim 'verb' or clause that cannot already be DB-driven.
If there is even one such, I have missed it.
> We need
> to do complex things and it takes a database to do it.
That is one way.
It can also be a more system-resource-intensive way than you might
imagine, even when all DB calls are correct and the relations are
optimally designed and implemented.
When they are NOT so, a malformed SQL select OR unexpected data or
schema changes can drive a server to its virtual knees in a New York
minute. Go play with OpenACS for a year or two with a console showing
system load...
> 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.
>
Exim already does a finite, but *very large* number of things no other
MTA can *easily* do.
More importantly, it does them sensibly, predictably, and efficiently.
Sufficient ability to code lets any other MTA be modified to do so also.
Eventually.
Or one can start anew with an all-DB model. See DBMail and PowerMail.
Wear latex.
F/OSS doesn't have what one could call 'market share'.
It has professional respect, acceptance, and adoption.
Much harder to earn, and not to be squandered.
Those are generally driven by terms such as:
'stable', 'trouble free', 'easy to install, configure, administer',
'well-mainained'
and - most of all: 'doesn't break'.
Not by an overabundance of complexity.
> 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. ;)
I suggest reversing those roles. Grab the 'wishlist' and submit some code.
'Fair Exchange' - reality, Alice Rosenberg style.
Apologies for interleave posting, but it seemed appropriate.....
Bill Hacker
>
> 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.
>>
>>
>>
>
