Date: 26/11/2008
| So over the last week or so I've brought online a new mail storage back end that I'm calling "Mail3". There are already some release notes in the v2 history page about it but I thought I'd talk a little bit about it in the blog. Basically a whole bunch of things are happening in the v2 code base all at the same time.
Firstly I'm really hammering on the memory leaks, trying to get them under control. I've fixed a lot already but the new code that I've written this week still leaks a fair bit. However the leak detection and fixing is working really well so it's almost fun.
Secondly I've finally rid myself of the hideous mime parser from Scribe v1.xx (and early alphas/betas of v2.00). Basically it sat inside the Mail object class and was well not well written. It's probably some of the oldest code in Scribe, dating back to when I sucked more at coding. Anyway I wrote a new MIME parser back in 2006 or something but couldn't work out how to integrate it without breaking everything so it stayed unused for years. Anyway I though while I was doing major earthworks in the code I'd blow the old parser away at the same time. So I did that and moved the ugly MIME flattening code into the Mail2 back end where it belongs.
Thirdly, Mail3. What is Mail3? Well Mail3 is the new mail store back end that I'm working on as the default mail store for Scribe v2. It's primarily a Sqlite database in a folder. I've chosen Sqlite for several reasons; it's small, it's cross platform (both the data format and the code), it's reasonably fast/robust and finally it doesn't have a restrictive license. Also you can also upgrade the format of objects (tables) easily enough. So it fulfills all the requirements for a new mail store. I may still choose to store large attachments outside the Sqlite database, I'm some what undecided on that at this point. Hence having the database in a folder.
So the Mail3 back end is working, you can create the mail store, manage the folder hierarchy, store mail into it etc. But the code doesn't support other types of objects yet, just folders and mail. One of the great things about Mail3 is that finally I'll have a 1:1 mapping between an incoming rfc822 email "image" and how it's stored in the database. So I'll be able to write out an exact (or functionally the same) version of a received email. Which is something that the Mail2 back end couldn't do because it munged the MIME segment hierarchy into a flat list of attachments. The Mail3 back end stores the MIME segments as rows in a table, with ParentId pointers to reconstruct the tree of segments.
Forthly, I've moved the parsing of email from the GUI thread into the worker thread doing the email download.
This should reduce the amount of GUI lockup during mail downloads.
Oh and lastly, the current code base can load more than one mail store at the same time. For instance you can have a mail2 file and a mail3 database open at the same time and they both appear in the folder tree as separate hierarchies of folders. There is only one problem with that, and that is the addressing of folders via paths is going to have to change. At the moment I'm not sure how that is going to play out but basically now that you can have multiple folders loaded things like filters and so on that reference a folder by it's path need to pre-pend a prefix on to the path to define which mail store the folder is in.
A v1 folder name:
/Inbox/Subfolder
Now needs a prefix to determine which store the Inbox belongs to:
/Store2/Inbox/Subfolder
However I'm not totally sure what that 'Store2' part should be. Should it be a complete path and file name to the store? or some arbitrary name that the user calls each mail store? or some UID that Scribe itself generates?
Yeah not so simple (to me at least).
|
