Partially retrieving messages is something important to support if you are targeting the mobile market. The reason for that is that not all devices come with huge flash disks, yet all E-mail boxes can contain huge E-mail messages. Imagine receiving an E-mail with three MP3 attachments and two CID embedded 750kb jpeg images on a mobile phone that has a flash disk of five megabytes.
I implemented a feature that makes it possible to switch between retrieval modes. I implemented two retrieval modes that are put in the framework: only getting the first mime part and getting everything.
You basically set the receive strategy of a folder to either a full message receive strategy, a partial message receive strategy or your own implementation that, for example, classifies between these two based on the message size (the size can be made available using the camel-lite CamelMessageInfo API, in other words: it’s available in the summary of the folder). More info here.
I also reimplemented a Camel IMAP implementation in camel-lite that fetched messages from an IMAP server. The original one copied the message in memory a few times. The new implementation will use the CamelStream API to immediately stream it to the file system while it receives the message.
This means that camel-lite, when compared with Evolution’s Camel, now improves memory and bandwidth consumption in four significant ways:
- The summary is read-only mmap()ed;
- When retrieving summary information from the IMAP server, tinymail’s camel-lite uses significantly less upstream bandwidth and it uses a lot less requests (sending a lot requests isn’t a very good idea on for example GPRS connections);
- When retrieving summary information from the IMAP server, tinymail’s camel-lite will periodically dump newly received information into the mmap while receiving is happening;
- When retrieving messages from the IMAP server, tinymail’s camel-lite does not copy the message in memory but rather streams it straight from the tcp/ip connection into the local cache-file. On top of that does camel-lite implement partially retrieving messages (which of course also reduces file system consumption if used).
I will now start working on getting POP support working with summaries. At this moment will an E-mail client like Evolution copy all (or filter, in the end it’s the same) the messages that are on the POP server into a local mail folder. On a mobile device with a small flash disk this isn’t a very good idea. It’s more interesting to store a summary and only cache the E-mails that the user really wants to cache. For IMAP this is but for POP this isn’t implemented in tinymail (for POP it is a lot harder to get it right). This is going to change of course. Partially retrieving messages from a POP service is also planned, but I’m uncertain if this is actually doable in a sane way.
Other things that are on the agenda for tinymail: uh, eum .. a lot. Check out the trac. For example: backing up and merging cache, removing attachments from an existing cache to reduce file system consumption, dealing with all sorts of strange error situations (like failing connectivity, batteries dying and the power of the device shutting down), GtkHTML support (still needs some work), I started trying to get some glib dependencies working on WinCE (so who knows, maybe someday tinymail on WinCE), maybe a default mail composer component, searching the summary of a folder, more status feedback, language bindings!, more documentation, etc etc, integration with existing calendaring tools, etc