The Goal: To create a lightweight and function email program for linux; with decent IMAP support; and basic groupware functionality. And to create one that doesn't use the legacy mbox format, and suffer the disadvantages associated with that format.

In addition, I'm trying to create a program that doesn't treat the user like a 5 or 85 year old. There aren't 500 pretty coloured buttons scattered across the application. However, this isn't to say the program isn't user friendly. Rightclick an address in an email message, and you'll get an option of adding that to your address book. Do the same to a URL, and the option to launch it will appear. In short, I'm creating an email program that you control, not one that tries to do what it thinks is best.

10/28/02 - So there haven't been any updates recently. There's a reason. The entire program has been rewritten in java from the ground up. So far, most of the basic functionality is implemented. Receiving works. Attachments work. Sending is about 80% done. Folder functionality (creating, deleting, renaming) works. This is all good stuff. The UI is basically the same, but there are some cool enhancments. I should have a public alpha up very shortly, and more tech information. But it's fairly safe to say that the new client has a fairly unique way of storing mail. It should make searching and fetching messages pretty easy and fast. Just stay tuned! =)

7/8/02 - A ton of new features, kind of. The application now remembers which message and folder you looked at last, and will attempt to reload those.

In addition, the program will now communicate with itself if more than one instance is launched, sort of. Which sounds absolutely useless, but any of the new commandline switches that are passed to a subsequent instance will be sent to the first. The commands are listed below, remove the quotes of course...

• "-check" - does just what you'd think it would. Checks your email accounts, and will send any queued mail.
• "mailto:address@goes.here" - Opens the program, and opens a composition window to the address specified.

So you can now use the application as your email client from other programs.

More importantly, I've done a bit of work on the java version. I've mastered the hell that is JTable, and have a working UI, and a working mail storage backend (using hsqldb). I really think java is the way to go. It's a really, really well thought out language (except for the JTable bit), and it's crossplatform. So that's all well and good. Expect more Java stuff this summer. If anyone wants to help out or has ideas, feel free to drop me a line with your thoughts and opinions on java.

6/13/02 - Index of folders is complete, and it works pretty damn well. There is also navigation to move to next/previous unread messages.

More pressing however, is what to do with the settings dialog. It needs to be redesigned, and badly. I've played around with it a bit, but still haven't hit the direction I want to go in.

And java. The java version is moving. I keep going back and forth on java. It's portable, but it's slow. It's not that slow anymore, but jtable is a bastard. Sigh.

4/30/02 - The indexing of folders is about halfway done. It's working and being stored in the .rc file, just need to get it displayed on the folderlist.

4/4/02 - Slowly, ever slowly. I have prepared a new version. Nothing new, just fixes and more fixes. I had to temporarily disable the "forward to" option in filters, since it doesn't work on the threaded model. There is a known bug: If you enter incorrect SMTP information, it will hang forever while it tries to connect to the smtp server. I'm aware, and working on a fix. For now, just don't enter bad information. :)

I'm going to try to get a new release out sometime soon, with 2 new features. SMTP authentication for one. And second, the folderlist will indicate the number of unread messages in each folder. Stay tuned.

Notes/Future:

• This is my first attempt at a large scale Linux application. I'm using Kylix to do the coding (think: Delphi for Linux). This also means that with a recompile and some cursing; I can have a Win32 version of the same program.
  
• The mail is stored in a binary format. Although you can't go in and read it with a text editor (and who does that, really), it is fast and pretty bulletproof. Searching 250+ (body search) messages takes under 4 seconds.
• After the .1 release is out, I want to work on cleaning up the UI before any new functionality is added.
• For the .2 release, receiving of email will be threaded
• For the .3 release, sending of email will be handled either by a thread or by an external program. This is the main thing holding up the creation of the sending mechanism right now... I don't want to create something until I'm sure it'll be thread/external program safe. I'm thinking of creating an out directory (which goes contrary to keeping the folders in one file, but...) and having the thread/external program walk it to send files. This is probably the safest way to do it, and the way I'll probably end up doing it.
• Filters. They're done, they work. Right now, if you have 10 filters, and 1 is a match, that filter is executed, then the next message is processed. However, with a simple change, it is very possible to have every filter applied to a message. I'm not sure if that's a good idea or not, but I can see pros and cons to both sides. I'll probably make it user adjustable.