[Dovecot] Adding new storage backend to Dovecot
I'm exploring adding a new storage backend to dovecot, storing mail in some sort of database, and had a few questions. Hoping someone here might be able to help :)
-Is all of the 'storage' specific code in housed in lib-storage/index? Would adding a new storage backend be as simple as recreating all of the public functions of the current /mbox or /maildir code such as they pertain to that storage mechanism?
-Where is the particular storage method controlled? I've had a look around but can't seem to find where the decision to use the 'mbox' or 'maildir' code is.
-Finally, if there isn't a filesystem associated with the mail storage area, obviously the index data code will need to change somewhere. Any ideas on the complexities of that?
Thanks!
Earl Dreller wrote:
I'm exploring adding a new storage backend to dovecot, storing mail in some sort of database, and had a few questions. Hoping someone here might be able to help :)
Other than the database storage engines already available, like maildir, mbox, and dbox?
Oh... did you mean SQL database?
Hmm... actually, wonder how it'd go with CouchDB...
-Is all of the 'storage' specific code in housed in lib-storage/index? Would adding a new storage backend be as simple as recreating all of the public functions of the current /mbox or /maildir code such as they pertain to that storage mechanism?
In my past experience with writing modules for Dovecot, yes it's often as simple as writing something to fill in the functions in the interface struct.
-Finally, if there isn't a filesystem associated with the mail storage area, obviously the index data code will need to change somewhere. Any ideas on the complexities of that?
You might want to investigate how the INDEX option to mail_location works.
-- Curtis Maloney cmaloney@cardgate.net
On Tue, 2008-04-22 at 20:15 -0700, Earl Dreller wrote:
I'm exploring adding a new storage backend to dovecot, storing mail in some sort of database, and had a few questions. Hoping someone here might be able to help :)
-Is all of the 'storage' specific code in housed in lib-storage/index? Would adding a new storage backend be as simple as recreating all of the public functions of the current /mbox or /maildir code such as they pertain to that storage mechanism?
That's the simplest way to get started, but you may want to add optimizations so that e.g. when FETCHing multiple different fields you ask all the wanted information from database at once, instead of one at a time.
-Where is the particular storage method controlled? I've had a look around but can't seem to find where the decision to use the 'mbox' or 'maildir' code is.
lib-storage/mail-storage.c mail_storage_create() receives the driver. It's configured by the user in mail_location setting, or if it's unspecified it's tried to be autodetected.
-Finally, if there isn't a filesystem associated with the mail storage area, obviously the index data code will need to change somewhere. Any ideas on the complexities of that?
You should keep using the indexing code, just make it be in-memory.
Look at http://dovecot.org/list/dovecot/2007-November/026632.html as an example, although I don't know if it still compiles. In any case don't even bother trying to implement this for v1.0, it's a lot easier with v1.1. v1.1 also has a minimal cydir backend that's easier to follow than mbox/maildir.
participants (3)
-
Curtis Maloney
-
Earl Dreller
-
Timo Sirainen