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.