Re: [Dbmail] Suggestion: SQLite backend

[Jeff Brenton]

Hello Steve,

SH> I would like to suggest a SQLite (http://www.hwaci.com/sw/sqlite/)
SH> backend. SQLite is a *fast* (they claim to be 4x faster then
SH> PostgreSQL) and small (lib is around 200Kb) embedded SQL engine.
SH> It's provided with full C/C++ code, and you can choose between
SH> dynamic or static linking.

The advantage dbmail using MySQL or PostGREShas over what SQLite would
offer is the ability for multiple machines to act as "front ends" to
the data store. SQLite is a single-machine solution, at a quick
glance.

In our situation, we have 2 (so far) front end servers, which provide
different levels of filtering for spam, as well as backup in case of
crashes. True, they're both dependent upon the same SQL box, but it is
hidden behind a firewall from attacks, and hasn't been down in over a
year, except for maintenance.

-- 
Best regards,
 Jeffmailto:[EMAIL PROTECTED]

Re: [Dbmail] Suggestion: SQLite backend

[Richard Barrington]

Just my opinion, but I guess that's not really the market that dbmail is aimed
at? If the complexity/overhead of pgsql or mysql is too much, why not just stick
with regular mail spools?

OTOH, the dbmail facilitates adding other dbms easy enough, so why not 
investigate
further. A Sleepycat Berkeley DB (Transactional Data Store version, possibly)
system could be worth looking at too.

One thing tho': After reading the SQLLite page, I'm not too sure if it would
play nice with all the server processes... ?

>I would like to suggest a SQLite (http://www.hwaci.com/sw/sqlite/)
>backend.