[Dovecot] Looking for plugin docs
Hello all,
I had gone through the wiki, but could not find any page about writing new plugins. Any pointers towards plugin api/docs will be very helpful.
with warm regards,
raj
On Sat, 2007-06-16 at 00:25 +0530, Rajkumar S wrote:
Hello all,
I had gone through the wiki, but could not find any page about writing new plugins. Any pointers towards plugin api/docs will be very helpful.
Unfortunately there isn't any plugin documentation currently. What kind of a plugin do you want to write? Looking at the existing plugins is probably the easiest way to get started. Also src/lib-storage/mail-storage.h is the most important API if you're going to access mailboxes.
The only plugin specific API is that Dovecot calls
On 6/16/07, Timo Sirainen tss@iki.fi wrote:
Unfortunately there isn't any plugin documentation currently. What kind of a plugin do you want to write? Looking at the existing plugins is probably the easiest way to get started. Also src/lib-storage/mail-storage.h is the most important API if you're going to access mailboxes.
Thanks for the super quick reply!
I am toying with the idea of storing mails in mysql. I was going though the archives and read the thread about this. I have also downloaded your previous attempt at this. I will go through the sources and ping you with questions.
regards,
raj
On Sat, 2007-06-16 at 00:41 +0530, Rajkumar S wrote:
On 6/16/07, Timo Sirainen tss@iki.fi wrote:
Unfortunately there isn't any plugin documentation currently. What kind of a plugin do you want to write? Looking at the existing plugins is probably the easiest way to get started. Also src/lib-storage/mail-storage.h is the most important API if you're going to access mailboxes.
Thanks for the super quick reply!
I am toying with the idea of storing mails in mysql. I was going though the archives and read the thread about this. I have also downloaded your previous attempt at this. I will go through the sources and ping you with questions.
I guess you mean http://dovecot.org/patches/mail-sql.tar.gz? I think most of the problem with it have to do with the SQL code itself.
If you're thinking about making it actually usable, it would be nice to store the message body instead as MIME parts (with separated header/body). That would allow identical attachments to be stored only once.
All headers could also be stored as rows (with ID<->header name mapping in its own table so they could be searched quickly), but the headers should probably still be left as their own complete header text block in another table so that the full header can be quickly downloaded.
On 6/16/07, Timo Sirainen tss@iki.fi wrote:
I guess you mean http://dovecot.org/patches/mail-sql.tar.gz?
Yes.
If you're thinking about making it actually usable, it would be nice to store the message body instead as MIME parts (with separated header/body). That would allow identical attachments to be stored only once.
Right now I am just experimenting, so do not know how far I will be able to work on it. But my idea is to have one db per email address. each db will have 3 tables, one table, let me call it header will have
- from address
- subject
- message date
- message size
- flags (replied, new etc)
- attachment_flag (boolean, true if there is an attachment)
Second table will have all other headers as well as the message body. Third table will have attachments as blobs, along with some metadata like content type, file name and so on.
The idea is to optimise for common webmail operations. Again this is just some experiments, if this works out it's great!
raj
All headers could also be stored as rows (with ID<->header name mapping in its own table so they could be searched quickly), but the headers should probably still be left as their own complete header text block in another table so that the full header can be quickly downloaded.
Friday 15 of June 2007 22:10:44 Rajkumar S napisał(a):
Right now I am just experimenting, so do not know how far I will be able to work on it. But my idea is to have one db per email address. each db will have 3 tables, one table, let me call it header will have
- from address
- subject
- message date
- message size
- flags (replied, new etc)
- attachment_flag (boolean, true if there is an attachment) Wouldn't it be better to put here id of attachments?
just my 0.5$
-- Łukasz Mierzwa
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
Wouldn't it be better to put here id of attachments?
I agree, these are just some idea that came to the top of my mind.
raj
Friday 15 of June 2007 22:10:44 Rajkumar S napisał(a):
Second table will have all other headers as well as the message body. Third table will have attachments as blobs, along with some metadata like content type, file name and so on.
Maybe You could make a checksum of an attachment and use it as a ID, this way You could have each unique attachment stored only once in db. What do You think?
-- Łukasz Mierzwa
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
Maybe You could make a checksum of an attachment and use it as a ID, this way You could have each unique attachment stored only once in db. What do You think?
Wonderful idea. I was thinking about the attachment id and identifying unique attachments right now :)
Thanks!
raj
Friday 15 of June 2007 22:10:44 Rajkumar S napisał(a):
Right now I am just experimenting, so do not know how far I will be able to work on it. But my idea is to have one db per email address. each db will have 3 tables, one table, let me call it header will have
To spam this ml more I must say that per user db is not that good idea, who will create missing db's ? I wouldn't let dovecot do it, a little better solution would be to make userid_table1, userid_table2 and so on, dovecot would need to be able to create new tables inside only one db which should be ok for security and speed (searching for a given user mails would be done on his own tables only).
-- Łukasz Mierzwa
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
To spam this ml more I must say that per user db is not that good idea
I must confess that I got this idea from Zimbra. I was just curious as to why they went for this instead of the obvious one table for all users. I will of course run some benchmark and then only choose the final design.
raj
Friday 15 of June 2007 22:45:38 Rajkumar S napisał(a):
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
To spam this ml more I must say that per user db is not that good idea
I must confess that I got this idea from Zimbra. I was just curious as to why they went for this instead of the obvious one table for all users. I will of course run some benchmark and then only choose the final design.
Speed is good, but what about security? You would need to create new db when creating new user, if userdb is not in mysql than You would need to connect to it with priviliges to create new db (quite high priviliges I think). Also I have no idea why this would be faster than per user tables.
-- Łukasz Mierzwa
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
Speed is good, but what about security? You would need to create new db when creating new user, if userdb is not in mysql than You would need to connect to it with priviliges to create new db (quite high priviliges I think). Also I have no idea why this would be faster than per user tables.
I agree with you, but I was just curious as to why Zimbra chose to one db per mail box. I have not finalised yet on any thing, (actually I am just starting).
raj
On Sat, 2007-06-16 at 02:15 +0530, Rajkumar S wrote:
On 6/16/07, Łukasz Mierzwa prymitive@pcserwis.net wrote:
To spam this ml more I must say that per user db is not that good idea
I must confess that I got this idea from Zimbra. I was just curious as to why they went for this instead of the obvious one table for all users. I will of course run some benchmark and then only choose the final design.
http://www.archiveopteryx.org/schema.html http://www.archiveopteryx.org/sql-schema.html might be useful reading too.
On 6/16/07, Timo Sirainen tss@iki.fi wrote:
http://www.archiveopteryx.org/schema.html http://www.archiveopteryx.org/sql-schema.html might be useful reading too.
Thanks!
raj
participants (3)
-
Rajkumar S
-
Timo Sirainen
-
Łukasz Mierzwa