Day: May 22, 2007

Hey Benjamin, good that you mention “creativity” and Mozilla in the same blog post.

I’m sure the people at Mozilla and the distributions have a slightly better solution to this current situation of having to do funny things in your configure.ac to figure absurd things out. Things like having to search which of the Mozilla development packages are available: a developer can choose between nss.pc, mozilla-nss.pc, firefox-nss.pc and xulrunner-nss.pc. I’m sure there are a few more too. Like nspr.pc, mozilla-nspr.pc, firefox-nspr.pc and xulrunner-nspr. And like xpcom.pc, mozilla-xpcom.pc, firefox-xpcom.pc and xulrunner-xpcom.pc. And of course also gtkmozembed.pc, mozilla-gtkmozembed.pc, firefox-gtkmozembed.pc and xulrunner-gtkmozembed. Just to make sure our configure.acs will be bloated like crap just for figuring out what the system actually has installed for those libraries.

I wonder what the use of pkg-config is if everybody starts doing that, Mozilla team?

For some fun reason they also decided to have -rpath in some of their “Libs: ” lines too. Making it totally fun for the maintainer to figure out why certain symbols can’t be found in a lot of circumstances (like when you used to have a function that was static, and now became a non-static, those rpath tricks will trick your linker into trying to use the installed libraries that are located in the prefix location if you once did a “make install”).

Awesome things if you don’t know that and expect sanity from pkg-config configuration files.

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.