Porting existing Evolution Camel providers to Tinymail

Tinymail’s camel-lite is still being developed extensively. While making changes, though, I made sure that the API that once got implemented by some existing custom Camel providers more or less stays the same. Myself, I added support for a bunch of Lemonade -and related features and improved the bandwidth consumption a lot in the IMAP provider, while adding support for summaries in the POP provider. These changes included a huge amount of bug fixing and other improvements too, of course. Especially on memory consumption. The majority of the changes, though, happened in the implementation, not so much Camel’s API.

Although an existing Camel provider usually needs a lot of bandwidth improvements before being acceptable for usage for Tinymail’s target audience (I looked at a lot of them, they do), you can very quickly make any such existing provider work with Tinymail. It comes down to rewriting one method: the CamelFolderSummary::message_info_load one. Noting that even the CamelFolderSummary::message_info_save stays the same. The load one needs to be rewritten because it’s in this method that in stead of read()-ing the data from the FILE*, you’ll have to implement getting the pointers from the mmap(). At entry of the method you’ll get the offset where the data that you wrote to the file using CamelFolderSummary::message_info_save starts. You are responsible for moving that offset further (for example += it).

The file I/O API of Camel has been modified to always do data padding, which is necessary for some architectures with mmap(), and to always end strings with a ‘\0’, which is of course important when pointing to offsets and using the pointer as a char pointer C string. You’ll always do it right if you use the standard Camel file I/O API.

I created a trac wiki page on the Tinymail documentation describing how to do this. It has some examples too. On bandwidth it’s of course vital to understand that a lot Tinymail based E-mail clients will be used on flaky networks like GPRS. Dealing with being offline (being very good at synchronization, while trusting that the connection will die at totally unexeptected locations in your code) and dealing well with timeout situations is of course very important. Compression and SSL are vital too.