jump to navigation

InterIMAP: Requirements January 20, 2009

Posted by atmospherian in InterIMAP.
1 comment so far

This post will serve as the official requirements documentation for the InterIMAP library. Please comment on this post with your suggestions for further requirements.

Core Requirements

  • Multi-threaded, multi-connection, asynchronous processing
  • Ability to support multiple accounts simultaneously
  • Ability to detect and retrieve only new messages for any or all folders
  • Ability to receive and save all file attachments, and message content
  • Ability to read/write messages in EML format
  • Optimized single process/connection synchronous client for repeated, specific purposes

Storage Requirements

  •  Provide 3 storage mechanisms: Virtual, Physical, Database
  • Ability to store folder and message data in memory temporarily
  • Ability to store folder and message data including attachments in a file on disk that can allow a mailbox to be cached, and to make that data portable.
  • Ability to store folder and message data in a relation database such as SQL Server, so that the data can be easily shared among other applications without having to distribute a local cache file, or stream the data to other services.
  • Ability to use Physical and Database storage mechanisms concurrently. 

API Requirements

  • Provide clean and clear interface to IMAP protocol
  • Provide easy to use Request/Response system
  • Provide clean object model

InterIMAP: Taking a step back January 20, 2009

Posted by atmospherian in InterIMAP.
add a comment

So i’ve been reading Steve McConnell’s Code Complete lately, and it’s got me thinking quite a bit about the new work i’ve been doing on the InterIMAP library. When i started working on the new implementation i had this grand view of a well thought-out, well designed system, and to a certain extent, i feel i accomplished that, but in some areas, i fell short. 

I initially felt that the new system would only ever need to connect to one server at a time, and as a result i wrote all the manager classes as singletons. I have since come to the conclusion that it may be necessary for multiple servers/accounts to be accessed concurrently, so that will be one of the major requirements going forward. Additionally, it may also be important to some people to be able to store the information retrieved from a mailbox in a full fledged RDBMS, as well as a “local cache” type system, so i will also be working that into the new architecture.

My next post will be a summary of what the requirements of the library will be. Please leave comments as to what you would like to have available in the library.

InterIMAP Redesign Notes January 6, 2009

Posted by atmospherian in InterIMAP.
1 comment so far

The time has come for me to continue work on InterIMAP. I have many changes and improvements planned for this library that will improve its usability. In an effort to flesh out my ideas and implementation, i will be putting together different posts for each topic that needs exploration. I welcome all comments and suggestions from those few of you who find their way here. 

To kick things off, here is a partial list of the features i am planning to implement or improve (in order of priority):

  • Better code structure utilizing more standard patterns
  • Completely Asynchronous client API
  • Improved offline cache system based on a ‘mailbox’ file that will contain the configuration information, messages and attachments in a zip format. This will allow an entire mailbox to be portable between different systems.
  • Build a basic graphical client to demonstrate the new asynchronous API and other features
  • Compatibility with Mono so the library can be used on Linux, Mac OS X, and any other supported platforms. 
  • Convert the graphical configuration editor into a component that can be dropped into any application.
  • Build a second configuration component based on WPF that can be easily customized. 

My next post will go into detail about what i plan to do about the code structure and how i intend to refactor, and reorganize everything.