On Tue, 6 Jun 2006, nodata wrote:
Seems to me that MySQL could somplify all the backend stuff
There are different SQL-Servers out there, e.g. Postgres.
Putting everything in a database would provide one benefit:
- Less storage space needed due to duplicated e-mail
Don't know, if such stuff will work out-of-the-box, but if the mails is broken into headers and bodies (for the message awhole and each MIME part), it can be very beneficial.
NOT putting everything in a database provides plays to Linux's strengths: everything is a file, meaning we can use all of the standard file-focused
And limits. Why does Dovecot has so many options for locking? ;-) What are the files days old in the tmp/ folders?
text processing tools. If everything is a file, backups and restores are a piece of cake.
Well, the problem with a file-based database (Dovecot's indexes etc. are in fact a database) is that you must use the same locking and/or terminate / suspend the service, otherwise there is the possibility that the data and the indexes are out-of-sync. The transactions of a full-featured DB will make backups and restores reliable, however, partial restores won't be possible without a good toolset. Do you know the spot of time _for_ _sure_ Dovecot has committed all internally cached data into the index- or control files?
Moving away from the filesystem will introduce other problems, e.g. one needs to introduce a full ACL implementation. And no operation can be easily performed in a DB manually, as you can with files. However, for the Dovecot files (e.g. keywords of a message) you need a toolset even today. For a SQL-Server, you need to know the structure and you can built a toolset with any language you like.
I'm neither advocating filesystem- nor DB-based mail storage, both has there strength and weakness. But I'd expect that you can rely on the DB's strangth for indexing and storing data well and you can focus on the processing of mails.
BTW: Cyrus uses a DB, doesn't it?
Bye,
-- Steffen Kaiser