I would like to review the portability/maintainence problems of current situation in 2.0. There is a consistent problem, most notably with static linkage to libraries at compile time for database backends. This makes maintainence more difficult because two (or more) builds must have taken place to handle the situation.
Solution A:
If you remember from before, I implemented a full libtool setup and it
dynamically loaded libraries. This is one way to go, but may not make
sense in the long run.
Solution B:
I have been following libdbi very closely. libdbi is a database
abstraction layer in C. Its not bulky like odbc, and its quite like the
perl DBI. Basically a move to a single driver libdbi would make sense
because you wouldn't have to rebuild to switch drivers. There is
already a set of 6 or so database backends already supported by libdbi,
some are:
mysql
pgsql
oracle
msql
firebird
sqlite
This would make it easy to port dbmail to other databases. You could
write a libdbi driver for all I care. I am very interested in a move to
SQLite to see how well the mail system scales under a real lightweight
database.
I have asked a friend of mine (DBA), to review the sql layout for
dbmail. I can only say he will probably rewrite the whole sql schema
for performance. Maybe a new database layout for 2.1.
Dan
signature.asc
Description: This is a digitally signed message part
