Why not use Maildir, or really any other standard scalable mail storage format? The most annoying thing in the universe is trying to export mail from one client to another with incompatible formats. Well, okay, maybe Vogon poetry is worse, but e-mail is a close second.
SQLite has a pretty great C API making it really easy to programmatically store, modify and retrieve data, which made it my first choice for runtime configuration data.
Adding another storage backend for the mail data would have meant a lot more code paths to support.
SQLite also has a lot of tools surrounding and supporting it (I particularly like SQLiteStudio) which allows querying/modifying/analyzing your mails with a huge number of programs, and using SQL - something I've found really useful!
With a sufficiently sane schema (which I hope we've achieved), transforming from the database format to any other format becomes really easy!
Also, since cmail is not really being developed with the intent to have people access their mail with a shell account (the main reason being that cmail users should not have to map to system users), supporting access formats on the server side is less of a priority - preferred access is via POP (already available) and IMAP (once it's done). The user database feature allows cmail users that ARE system users to control their own database.
An exporter to convert to/from Maildir is a planned feature :)
Hear-hear. Aside from a big directory of ascii text files, I can't think of a more future proof method of storage. So sqlite has that going for it, in addition to the extension API - which is awesome. I recently had to write some integration software for Kronos and some no name security system, as I was already storing the data in sqlite I decided to handle the Kronos business logic with a loadable extension - it was a pretty pleasant experience. Actually, I'm pretty sure there is an extension out there that allows you to use a directory of CSV files for table storage...
I've been thinking of using one of their schemas as a base for doing something similiar for an email client/interactive mail archive type thing (think: hyperkitty/pipermail).
Also notmuch has done some work for mapping email to xapian for search/tagging/indexing -- could also be a good source of inspiration I think.
I was aware of dbmail, but did not peruse the source in-depth, in part because it does not in itself implement SMTP.
Archiveopteryx I did not know, but thanks for the tip!
Using their databases as the basis for new tools has the obvious benefits of cross-compatibility, though there's always the drawback of database cruft that accumulates by virtue of differences in implementation or project goals.
Comments
Why not use Maildir, or really any other standard scalable mail storage format? The most annoying thing in the universe is trying to export mail from one client to another with incompatible formats. Well, okay, maybe Vogon poetry is worse, but e-mail is a close second.
Well one reason being I really like SQLite.
SQLite has a pretty great C API making it really easy to programmatically store, modify and retrieve data, which made it my first choice for runtime configuration data. Adding another storage backend for the mail data would have meant a lot more code paths to support.
SQLite also has a lot of tools surrounding and supporting it (I particularly like SQLiteStudio) which allows querying/modifying/analyzing your mails with a huge number of programs, and using SQL - something I've found really useful!
With a sufficiently sane schema (which I hope we've achieved), transforming from the database format to any other format becomes really easy!
Also, since cmail is not really being developed with the intent to have people access their mail with a shell account (the main reason being that cmail users should not have to map to system users), supporting access formats on the server side is less of a priority - preferred access is via POP (already available) and IMAP (once it's done). The user database feature allows cmail users that ARE system users to control their own database.
An exporter to convert to/from Maildir is a planned feature :)
Hear-hear. Aside from a big directory of ascii text files, I can't think of a more future proof method of storage. So sqlite has that going for it, in addition to the extension API - which is awesome. I recently had to write some integration software for Kronos and some no name security system, as I was already storing the data in sqlite I decided to handle the Kronos business logic with a loadable extension - it was a pretty pleasant experience. Actually, I'm pretty sure there is an extension out there that allows you to use a directory of CSV files for table storage...
Did you have a look at http://dbmail.org/ ? And/or http://aox.org/ (Archiveopteryx) ?
I've been thinking of using one of their schemas as a base for doing something similiar for an email client/interactive mail archive type thing (think: hyperkitty/pipermail).
Also notmuch has done some work for mapping email to xapian for search/tagging/indexing -- could also be a good source of inspiration I think.
I was aware of dbmail, but did not peruse the source in-depth, in part because it does not in itself implement SMTP.
Archiveopteryx I did not know, but thanks for the tip!
Using their databases as the basis for new tools has the obvious benefits of cross-compatibility, though there's always the drawback of database cruft that accumulates by virtue of differences in implementation or project goals.