On Sun, Aug 13, 2006 at 05:39:14PM +0200, Nicolas George wrote: > I believe SQLite would be a better choice than PostgreSQL or MySQL: > PostgreSQL- or MySQL-based solutions would require installing a server (most > people do not have that already), setting up a database and database > account. SQLite is just a library embedding the SQL engine, and the database > itself is a single file. While SQLite is some amazing code, it really requires a single process to manage the coherency of the system. I would like to continue to use e.g. procmail to "deliver" my mail -- marking some messages already read before delivering them (duplicates, uninteresting automatically generated messages that I occasionally search through but never _read_, etc), classifying nonspam, possible spam, definitely spam. Because I want both mutt _and_ procmail to be able to modify the mail storage, I believe SQLite is the wrong approach; you would necessarily wind up building something rather like postgresql's postmaster, or mysqld, etc. Both mutt and your mail delivery system (procmail, postfix's 'local' agent, exim's local channels, etc) would need to communicate with the master mail database process. Another possible approach using SQLite would have procmail or the other local delivery agents deliver mail as usual, and have mutt do the database maintenance as mutt reads the inbox, similar to a cache. I dislike this idea, as it places mutt in the 'delivery' path; other tools written to work with email would necessarily need to be aware of 'pre-mutt' and 'post-mutt' versions of mails, and take appropriate actions. I have nothing against caches :) but somehow it feels like other tools should be able to enjoy the benefits of the system without going through mutt. And I think that would be easiest if the database system were a full-fledged database engine such as postgres. > I would really like to hear your preliminary thoughts about that project, > especially about the database structure. I expected that I would have several tables: addresses address_id, address subjects subject_id, subject messageids messageid_id, messageid (ugh :) status email_id, read, old, replied, deleted_date, sent_date (maybe this table should be broken up a bit?) emails email_id, date, body (store both sent and received mails) email_from_ email_id, address_id (one entry for the From_ address) email_from email_id, address_id (one entry for each From: address) email_to email_id, address_id (one entry for each To: address) email_cc email_id, address_id (one entry for each Cc: address) But, this was how I _thought_ about building it; I never got further than thinking...
Attachment:
pgpGwTKwZWZWz.pgp
Description: PGP signature