jump to navigation

InterIMAP Progress Update #7 May 22, 2008

Posted by atmospherian in InterIMAP.
trackback

I am very excited to let you guys know that the re-engineering of the message processing architecture is currently stable and working. My new system for processing message content has not only reduced the number of send/receives from the server to a maximum of 3, but has reduced the code of IMAP.cs by roughly 50-60% making it much cleaner and easier to read and understand.

The original way of processing the message content, which was written by the original author of the code, Rohit Joshi, worked well, except for the fact that it choked on many messages from Gmail, which as i understand is one of the main services that this library is being used with (Exchange is the other). Modifying his code to work with gmail proved nearly impossible due to the extreme variations that can occur in body structure. The process involved first getting the BODYSTRUCTURE of the message, parsing that and then getting each individual BODY[x(.x.x)] section. While this is a valid solution, it is very difficult to write something that can parse the BODYSTRUCTURE in its seemingly infinite variations.

The solution is to pull the full content of the message directly using the BODY[] parameter. The result of this command is every section of the message being return in sequence, usually demarcated with a ‘boundary’ value (except in the case of messages with a single text/plain content type). After this boundary, is the header meta data for that section, which can include the content-type, transfer encoding, disposition, etc. making it easy to parse this header data and properly construct IMAPMessageContent objects.

What does this mean for you? it means that there is now a complete, accurate, and efficient process in place for retrieving the message content from both gmail and exchange.

So whats next? Well, during testing, it became clear to me that for large accounts, having all of the message attachments stored in memory could require a significant amount system resources, much more than an email system should need. So with that in mind i am starting to think about ways to store attachments outside of the main cache file, so that when the cache is loaded, the attachments arent loaded until they are requested.

Advertisements

Comments»

1. ross - May 22, 2008

cool. get it working, dude

2. Rasta - September 29, 2008

Thats really cool, i appreciate the work you guys do.

3. Ufuk Kayserilioglu - November 3, 2008

I am currently experimenting with your library. I found it very nice and clean. However, I have added a few features to the library (like fetching a message by UID, which when used internally gets rid of all the loops over all messages to find the right message, etc.). what is your preferred way of accepting these changes.

Also, I have a problem with how the library tries to parse the message body itself. The IMAP server already does this for us, so why should we be doing it all over again? I realize that parsing the BODYSTRUCTURE result could be non-trivial but there are many clients (open-source ones as well) that successfully do it. So why not do it right like they do? I would like to work a little bit on this, do you have any pointers and/or comments?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: