Ilja,
I've just build and uploaded experimental debian packages for dbmail-2
deb http://debian.nfgd.net/debian experimental/
packages:
dbmail-mysql
dbmail-pgsql
dbmail-mysql-ldap
dbmail-pgsql-ldap
Maybe a silly idea; Would it be feasable to implement the database and
auth layers as plugins or shared libs allowing runtime selection through
the config file.
As more auth layers and database backends will be supported the
permutations of possible builds will explode, making it virtually
impossible for me to build a full set of debian packages. I'm sure
people working on packages for other distros will hit the same problem.
Ilja Booij wrote:
Hi all,
The 2.0 branch of dbmail is becoming "stable". A lot of code has been
changed, almost all of it in the database layer.
* merging db code
As I mentioned about1 1/2, 2 months ago, the database code has been
merged together, leaving only 2 (MySQL and PostgreSQL) database specific
.c files of about 300 lines of C-code each. Implementing code for
additional database
systems (Oracle, DB2, Firebird, SAPdb etc) should be quite trivial.
* extra table
There is an extra table in the database (physmessage, for 'physical
message', as opposed to virtual message) which links messageblocks and
messages. This gives us great speed up with regard to copying messages.
In the old database scheme, copying a message meant copying all
messageblocks, which is slow. Now, only a new entry in the messages
table has to be made, which points to the same physmessage record.
This speed up was needed because copying occurs quite frequently; IMAP
has no MOVE command, so a move is done by a COPY followed by a delete.
This occurs often, for instance when a client does not really delete,
but moves a message to the Trash folder
The messages tables has been changed like this: it holds an extra
physmessage_id field. The messagesize, rfcsize and internal_date fields
have
been removed.
the physmessage table holds: messagesize, rfcsize and internal_date
the messageblks table now holds a physmessage_id instead of a message_idnr
* extra column in users table
The users table now holds the column "currmail_size", which holds the
current
mailsize of a user. This prevents the calculation of the used quotum every
time this figure is needed. currmail_size is now calculated every time the
size of a user's mailbox changes.
I've done quite a lot of testing, using the MySQL backend. PostgreSQL
should be
tested further.
DBMail 2.0 is now ready to be tested by more people to squash all
remaining bugs.
Please pull the latest revision from cvs* and test it!
cheers,
Ilja
*
use: "cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot-dbmail co -r
dbmail_2_0 dbmail" to get dbmail 2.0
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
