I’ve gotten a few e-mails now from people asking me why I have chosen CoreData over a standard mail format like Maildir. Kiwi will support Maildir for importing and exporting your mail (via Libetpan), but it will not be using it as it’s primary storage method. Here’s a few of the pro’s and con’s for each:

CoreData

Advantages

Fast

Atomic Commit

Manages object graph

Simplifies implementation of multithreading

Allows for easy integration of added metadata like tags

Disadvantages

Format is application specific

Makes Spotlight integration more difficult

Maildir

Advantages

Standard mail storage format

One message per file makes Spotlight integration easy

Small memory footprint

Disadvantage’s

Slower

Makes persistence code much more complex

Makes implementation of the interface much more complex

It’s impossible for me to ignore the speed and ease that CoreData brings to the table. While there are definite advantages to using an open standard like Maildir, CoreData is going to make it easier implement more innovate features. In a way the format for Kiwi is not proprietary, since the application will be open source and everyone will have access to the schema for the SQLlite database. So hopefully, CoreData will be the right choice and will allow us to build a better app faster.

Ideally in Kiwi, everything would be pulled from the server during launch, but this limits Spotlight integration and it makes offline reading of e-mail impossible. I originally toyed around with storing e-mail in the MH mail format because it’s an open format and every message has it’s own file. Persistence is never easy, especially when people demand stability, and implementing the MH format is no exception. Knee deep into writing file I/O code, I took a step back and rewrote with CoreData.

Previously, the interface fed off of instance variables in objects via bindings. It was clear that this was making persistance and multithreading more complex than necessary. So I packaged all the code together that performs IMAP calls and sat it on top of CoreData. Now, instead of writing retrieved IMAP data to local instance variables, it writes directly to the CoreData store. The interface sits on top of a copy of the CoreData store and feeds off of it with Cocoa bindings.

If I had used the MH format, I would have had to manage all of the relationships between Folders and Messages and more importantly, I also would have to insure consistency in the event of crash. CoreData has been a huge help in this regard, it maintains the referential integrity for me and it keeps changes in memory until they are committed. Now users of Kiwi can be confident that their data is stored in a SQLlite database that is consistent across sessions.

Moving from a graph of NSObjects in memory to CoreData has not been without trial and error, though. For about the past day, I’ve been trying to figure out why one table hasn’t been displaying data that exists in the database. I double checked all of my connections, I tripled checked my methods and still, the table was displaying a lone and empty cell. Finally, today I figured it out: I had forgotten to switch the controller in Interface Builder from Class Mode to Entity mode. I made the simple switch, and my tableview (thankfully) came to life.

I have to say that these new technologies, like Bindings and CoreData, solve problems but they also introduce yet another learning curve for developers on the Mac platform. In the end however, I think CoreData is going cause alot of developers out there to take a second look at their persistence code and wether CoreData and Bindings can help them spend more time on other features.