• The primary task that has to be completed is the porting of Zoe from a WebObjects infrastructure to a Tapestry one.
• Almost all of the classes need Javadoc comments added. 
• There are a number of features that we want to implement or enhance. Most of them are listed on the Requested Features page.  However, we are holding off on most of these until we have finished the conversion to Tapestry. 

Here is a little overview of how messages get processed in Zoe and who does what. I thought that might be useful when tracking down "issues"...

(1) When the application get started, the first thing that get setup is the SZServiceAgent. The service agent is the beast that will poll your emails accounts to retrieve messages. There is one service agent per "identity" (an identity being the equivalent of an user). The service agent is triggered by a Timer to do its things every now and then.

(2) When triggered, the service agent will iterate through all the SZAccount (aka email account) attached to a given identity. First, it will ask for a message uid and check if it already knows about it. If the service agent think that this is a new message it will pull it from the account and create a SZMail out of it. A SZMail is simply a thin wrapper around most JavaMail methods. It also knows how to store itself with the help of a SZMailStore. This is the only time a message is written to the file system. The message will be stored in a time line structure reflecting the message sent date. The name of the file itself is the message uuid. Once the SZMail is written is the SZMailStore, the SZMail is enqueued in an incoming queue. There is one incoming queue per identity.

(3) The SZMailProcessor kick in at that point. That's the beast that does the bulk of handling the messages and transforming them into something more structured. Once again, there is one mail processor per identity. The mail processor is an "observer" of a queue. When something get added to the queue, the processor get notified and starts doing its things. The first thing the mail processor will check is to see if there is already an SZEnvelope for a given SZMail. If there is none, the processor will create an envelope out of the mail. The envelope get created in the identity's object store. There is one object store per identity.

(4) Creating an envelope out of a mail triggers a chain of events that will decompose the original mail into its constituent parts. This is where the bulk of the work is done. A mail will get split into a dozen or so different objects. And all of those objects will get automatically indexed along the way. With all their relationships interconnected.

The End.
-Raphael

• "shutdown" to shutdown a running application
• "debug" to turn on/off debugging.
  You can pass this to Zoe while it's running to toggle debugging on and off at any point.
  
• "check" to run an integrity check on the data storage.
• "optimize" to optimize the data storage.
• "rebuild" to rebuild the entire data storage.
  In the process this will also generate new permanent links for each e-mail.