It’s been a long time since I’ve been as excited and motived as I am now to develop an app. I’m revved, so much so that I’ve been glued to my computer for the past few days and it’s sure payed off. Kiwi now has tabs; e-mail is been rendered using CSS, a sudo-preprocessor and WebKit; Major performance improvements; and the Interface is getting cleaned up. Now that I’ve sketched out the app, it’s time to start filling in the details that are going to make this thing great. And I probably shouldn’t say “I” anymore, a few of my friends have jumped in and are helping out now. One of my friends from the University of Illinois, Bob Van Osten, has joined in providing alot of added interface code, including the tabs and many of the interface tweaks. He’s also actively working on getting SMTP up and running, which i’ve neglected completely so far. My friend Chad Weider, has been assisting in writing up regular expressions to help process e-mail. Here are more screenshots, the interface is a little rough right now because of the tabs, but we are working on cleaning that up.

Kiwi is coming along quite nicely now. Much of my progress is thanks to Cocoa bindings, which have made glue code nearly non-existant. Bindings are fantastic, but they come with a very steep learning curve and I feel like I’m just beginning to grasp them now. Anyway, here’s a bit of what I’ve gotten done in my app:

• Account settings are now configurable and SSL is supported
• Subscribed folders are listed on the left in an outline view
• Unread status is parsed for messages
• Sender information is parsed
• MIME decoding is supported so e-mail output is greatly cleaned up
• Connection support has been improved, resulting in a huge speed up
• There is a toolbar and a toolbar item that loads e-mail, finally!

Of course a picture is worth a thousand words, so take a look at how far it’s come:

So what do I have planned once basic e-mail support is complete? I hope to add tab support and e-mail rendering using CSS and Webkit for very customizable output. Stay tuned.

I’ve been using the wicked cool Textmate to do programming for the last week. It’s one of those apps that after every launch you find a new little feature that draws you in even more. Each little feature makes you more productive and your workflow more streamline. Earlier this week I had one of those moments with Textmate when my friend Chad mentioned that when he was doing work in Eclipse this summer, there was this great feature that would allow him to add comments like: //TODO This is something I need to do And at the bottom of the window there was a pane showing him what he marked as to do for that file. After, hearing this I played around with Textmate looking for something similar, and there is! If you add comments like shown above to your files, and then run the command TODO, it will display a nice window with hyperlinks to all the things you marked. Very cool: Take a look below:

I’ve been doing some hardcore hacking on my pet project, an e-mail client named Kiwi, and what you see above are it’s first breaths of life. It’s not much to look at, but it’s significant progress.

I am finally able to load the inbox and display messages when they are selected in the rightmost pane. Don’t mind the ugly e-mail output right now, I’ve yet to do any parsing of the headers and the MIME data.

Here’s a cool trick that converts man pages to postscript and opens the file in Preview. Add this to your .tcshrc file in your home directory:

alias preman 'man -t !^ > /tmp/!^.ps; open /tmp/!^.ps'

Then to open man pages in Preview type:

preman NAMEHERE

I discovered the incredibly useful unix program screen just recently. It allows multiple terminal sessions running at once and it provides easy access for switching between sessions. To run the command type: screen Once screen is running you can do Control-AC to create a new window and use Control-A followed by a number to switch to that session number. And the best I’ve saved for last, if you close your terminal session and want to get back to the screen you were working on, just type: screen -r Magically, screen will come to life just as you left it, which makes it great for running on remote servers.

Due to my dissatisfaction with existing mail clients, I’ve been slowly grinding out a simple IMAP client. There was no way I was going to write my own IMAP client, so I scoured the web and came across a few libraries. So I wanted something that was clean, fast and written in C, C++ or Objective-C and ideally thread safe.

C-Client C-Client was written by the man at the University of Washington who invented IMAP4rev1, so you can be sure it implements the RFC fully. However, the code is downright atrocious, it’s a mess of spaghetti code and undecipherable documentation. There are two programs which are samples to help aide in understanding the library. One of the samples is an old mail program written for NeXt and the other is Pine. If you haven’t looked at the Pine code, I urge you not to, it burns the retinas. So despite C-Client implementing the spec perfectly and being a very fast library, I found myself unable to understand the wild style that the library was written in.

JavaMail The JavaMail API’s look really clean, but I was leery of implementing a core part of my e-mail app on the Java-ObjC bridge. In a past project, LaserLine at UIUC MacWarriors, I was forced to use the Java-ObjC bridge and was not pleased. I found it a hassle to deal with and a slow alternative to native C code.

Camel Camel is the mail library that rests under Evolution and it’s designed to access a number of different kinds of data stores. It’s written in plain C and relies on a number of data structures that reside in the underlying Gnome libraries. The libraries that it does rely on are non-graphical so getting them up and running wasn’t a big deal. The code base is massive, with support for an amazing array of data stores. Some people are very leery of the IMAP support inside the library, apparently it works but it’s not exactly thread safe. Camel really is a mountain of source, and the fact that they pretended C is object-oriented when writing the library doesn’t help things. What really made me drop the ball was this:

Even with all of it’s problems, this is the most stable and featureful remote backend in existence. It just isn’t very easy to maintain. I should really add more detail here, but I just don’t care - I barely understand the code either, and I rewrote it anyway. Maybe others can update it. Source

When the guy who created the monster says he doesn’t understand it, I’ll look elsewhere.

Pantomine Pantomine was the only Cocoa/Objective-C IMAP library that I found, which is a huge plus for this library. But it’s slooooowww and no one has done any work on the project for a number of years. One of the objectives of my mail client is for it to be blazing fast, so Pantomine is a no.

LibEtPan LibEtPan is the best IMAP library I have found. It’s fast, written in pure C and it doesn’t require really any dependencies. The function names are clear and the data structures are intelligible. There is documentation provided with the library but it’s lacking in a number of respects, but the code is so clean that many times you don’t even need the docs. The implementation is very robust with support for high level access, so that different mail drivers can sit underneath. For example you can use the high level function to talk to either IMAP or POP3 without having to change any code, you just change the driver. The available functions for the high level stuff is limited because it has to be the intersection of both IMAP, POP3 and the other protocols it implements. The lower level stuff is very clean as well, and implementation specific. For example, in my project I am using the lower level IMAP drivers because I don’t intend on supporting any other protocols and I get the niceties of IMAP. This library is in active development and the developer is very responsive to questions, if you’ve got a need for a mail library I highly suggest this one.