Maildir is a mail storage format developed by D. J. Bernstein for qmail. In Maildir, every message is a file. Every logical mail folder in Maildir consists of 3 directories in file system - "tmp", "new" and "cur". These 3 directories correspond to 3 stages a message undergoes as it arrives:
1. When a message is being downloaded, it is saved into "tmp".
2. When download finished, the message is moved (hard-linked) into "new". Until this moment the message is considered non-existent.
3. Messages in "cur" are just like messages in "new". The difference is that those in "cur" are no longer new mail: they have been seen by the user's mail-reading program (the message gets flags representing it's state: read/unread starred, flagged, etc.)
Useful links:
http://cr.yp.to/proto/maildir.html
http://en.wikipedia.org/wiki/Maildir
http://wiki.dovecot.org/MailboxFormat/Maildir
http://www.courier-mta.org/maildir.html
http://wiki.mutt.org/?ExtendedMaildirFormat
воскресенье, 6 июня 2010 г.
Building Thunderbird
is relatively easy. Just follow the build documentation.
Your "nightly" Thunderbird executable will be in \comm-central\objdir-tb-release\mozilla\dist\bin\
# Get the comm-central (mailnews) sourceIf you're on Windoze, you need to install the Mozilla Build suite of Unix tools. You will also need a C++ compiler and an SDK (set of include and lib files). To build 1.9.1 and newer code use MSVC 2008 Express and Windows 7 SDK. You will also need to solve the missing ATL header problem.
hg clone http://hg.mozilla.org/comm-central/
cd comm-central
# Update and get the remaining source (mozilla-central)
python client.py checkout
# Setup a basic .mozconfig file
echo 'ac_add_options --enable-application=mail' > .mozconfig # let's build Thunderbird...
echo 'mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-release' >> .mozconfig # ...in this directory...
# Build
make -f client.mk
Your "nightly" Thunderbird executable will be in \comm-central\objdir-tb-release\mozilla\dist\bin\
The beginning
Hi ALL. I'm Andrey and this is my mozilla hacking blog. Welcome!
I was chosen as a google summer of code 2010 student. I'll be working on Thunderbird, helping David Bienvenu with Pluggable Mail Store.
Historically TB was written to store emails in Berkeley mbox format (one mbox per folder). Berkeley mbox has some issues, originating from its nature - all email for a mail folder is stored in a single file. The issues are:
1. Mbox file needs to be locked by the program that modifies it. Otherwise, inconsistent writes to mbox file by different programs will damage it. The problem is even worse: not all file systems support locking, and sometimes there are multiple incompatible locking mechanisms.
2. It's very costly to delete email from mbox. Involves file copying.
3. If mbox file is damaged, you can lose all email for the folder (e.g. your Inbox). Happens sometimes with TB.
For these and other reasons it would be great to be able to store email in different formats that do not have these issues.
Rather than to rewrite code to use another format it was decided to use the power of XPCOM - interfaces - define a pluggable mail store interface that a particular mail store format can implement, as an XPCOM component.
David defined such an interface in his patch to the mailnews code. He is now working on rewriting TB code to use this interface. He moved all mbox-specific code into a new component. My task is to implement this interface for Maildir.
I was chosen as a google summer of code 2010 student. I'll be working on Thunderbird, helping David Bienvenu with Pluggable Mail Store.
Historically TB was written to store emails in Berkeley mbox format (one mbox per folder). Berkeley mbox has some issues, originating from its nature - all email for a mail folder is stored in a single file. The issues are:
1. Mbox file needs to be locked by the program that modifies it. Otherwise, inconsistent writes to mbox file by different programs will damage it. The problem is even worse: not all file systems support locking, and sometimes there are multiple incompatible locking mechanisms.
2. It's very costly to delete email from mbox. Involves file copying.
3. If mbox file is damaged, you can lose all email for the folder (e.g. your Inbox). Happens sometimes with TB.
For these and other reasons it would be great to be able to store email in different formats that do not have these issues.
Rather than to rewrite code to use another format it was decided to use the power of XPCOM - interfaces - define a pluggable mail store interface that a particular mail store format can implement, as an XPCOM component.
David defined such an interface in his patch to the mailnews code. He is now working on rewriting TB code to use this interface. He moved all mbox-specific code into a new component. My task is to implement this interface for Maildir.
Подписаться на:
Сообщения (Atom)