[Dovecot] Writing a new mailbox access module
Timo Sirainen
tss at iki.fi
Sun May 13 15:43:17 EEST 2007
On Sun, 2007-05-13 at 14:29 +0300, Tom Alsberg wrote:
> * The user sees one mailbox M, which contains all the messages in the
> mailboxes A and B.
>
> * A and B are both already accessible by existing Dovecot mailbox
> access modules, but possibly by different modules (e.g. A is an
> mbox, B is a Maildir).
>
> * Any write operation (creation of a new message, etc.) is eventually
> performed on B.
>
> * As soon as a message that was in A is accessed (either for read or
> for write), it is transferred to B.
So individual messages are separately moved to ~/mbox while they're
being read? And by read what exactly do you mean? When IMAP client reads
the message, or when the message is marked as \Seen?
The biggest problem I see with this is message UIDs. IMAP requires that
the mailbox has growing UIDs. The message UIDs preferrably also
shouldn't change, otherwise the clients will see them as new messages.
This can't really work with the current Dovecot code, for example:
1. Move message with UID 2 to ~/mbox
2. Move message with UID 1 to ~/mbox
To avoid UID changing the 2rd step would require that the message is
inserted into the mbox file as the first message. Dovecot has no code to
do that.
Another possibility would be to allow messages to be in the mbox file
non-sorted. That would probably be easier to implement than insertion
code. Actually I think that would only require removing a few checks
from mbox-parse.c
> I have just skimmed again through the mailbox code (which I last
> looked at over a year ago, back when it was in alpha releases), not
> going too much into details. From past experience and current
> skimming, working with that code doesn't seem too straightforward,
> though.
I've been trying to make it easier to implement new storages in CVS
HEAD, but there is still a bit of work to be done. Cydir is the simplest
possible storage backend, so looking at that could be useful.
> I can think of how to implement the logic I described on its own
> (i.e. as a library with a few functions), but not sure how difficult
> it will be to interface it with Dovecot. Is there any
> developer/module writer's guide somewhere that explains the mailbox
> access module interface?
Unfortunately not. I've been thinking about writing something to wiki ->
Design about this too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070513/646cd4cd/attachment.pgp
More information about the dovecot
mailing list