[Dovecot] plugin development guide for non-FS backing store
Hi, folks.
I was wondering if anyone has some sort of guide or reference on
plugin development.
We are trying to develop a non-filesystem backing store.
So basically we do not store mailboxes for users in local filesystem.
We do RPC call
to fetch from fileservers.
Thank you in advance.
Chang
On Sep 20, 2009, at 4:42 AM, Chang Song wrote:
I was wondering if anyone has some sort of guide or reference on
plugin development. We are trying to develop a non-filesystem backing store.So basically we do not store mailboxes for users in local
filesystem. We do RPC call to fetch from fileservers.
Well, the best there exists currently is http://dovecot.org/list/dovecot/2007-November/026632.html
but it's for an old Dovecot version. You really should start with
Dovecot v1.2.
Do you need to use some existing mail database or is it something
completely new? I'm just wondering if my upcoming dbox filesystem
abstraction layer would help you.
Anyway, basically just go and look at lib-storage/mail-storage.h and
mail-storage-private.h and mailbox-list.h and mailbox-list-private.h.
Implement those using your RPC calls, using index_*() functions
wherever possible, just like the filesystem backends. You can also
make Dovecot use in-memory indexes only with your database, although
it probably would be better to just create them on local disk and act
as kind of a cache.
Hello, Timo. Wow. directly from the creator ;-)
Thanks for the reply.
This is something completely new. We are connecting to our pre-existing custom-made mail server. IMAP needs to be plugged into the infrastructure.
So basically we can simply use existing index_* since we need to have index files (on local fs) no matter what.
I saw dbox source file there. Is the layer stable (as far as API goes)? Tell me more about the abstraction layer.
Thanks a lot!!
Chang
On Sep 21, 2009, at 2:44 PM, Timo Sirainen wrote:
On Sep 20, 2009, at 4:42 AM, Chang Song wrote:
I was wondering if anyone has some sort of guide or reference on
plugin development. We are trying to develop a non-filesystem backing store.So basically we do not store mailboxes for users in local
filesystem. We do RPC call to fetch from fileservers.Well, the best there exists currently is http://dovecot.org/list/dovecot/2007-November/026632.html but it's for an old Dovecot version. You really should start with
Dovecot v1.2.Do you need to use some existing mail database or is it something
completely new? I'm just wondering if my upcoming dbox filesystem
abstraction layer would help you.Anyway, basically just go and look at lib-storage/mail-storage.h and
mail-storage-private.h and mailbox-list.h and mailbox-list- private.h. Implement those using your RPC calls, using index_*()
functions wherever possible, just like the filesystem backends. You
can also make Dovecot use in-memory indexes only with your database,
although it probably would be better to just create them on local
disk and act as kind of a cache.
On Sep 21, 2009, at 12:32 PM, Chang Song wrote:
This is something completely new. We are connecting to our pre-existing custom-made mail server. IMAP needs to be plugged into the infrastructure.
OK, so you do have some existing mails that need to be accessed.
So basically we can simply use existing index_* since we need to have index files (on local fs) no matter what.
Right. And even if you didn't use actual index files, the same
index_*() functions will be useful for in-memory indexes.
I saw dbox source file there. Is the layer stable (as far as API
goes)? Tell me more about the abstraction layer.
It probably won't be useful then, because if you have existing mails
they won't be in dbox format. I guess you could maybe do some kind of
translation on the fly, but that could just be more trouble than
implementing your own storage backend.
I'd probably start by implementing your own mailbox-list backend. Then
you could see that IMAP's LIST, CREATE, DELETE, RENAME commands work.
That should be somewhat easy to do. You could temporarily just use
e.g. Maildir backend and:
mail_location = maildir:~/Maildir:LAYOUT=rpc
After that works, create "rpc" mail-storage as well. cydir might be a
good an easy example. The biggest problem is the "mailbox_sync" part.
It's easiest if you can just trust that the local index files are up-
to-date, otherwise you somehow need to figure out what had changed in
the mailbox and update the indexes.
participants (2)
-
Chang Song
-
Timo Sirainen