Contract Deliverables

Set of libraries with mail-specific code and as little else as possible

My thinking is that for now these can be built directly from a mozilla tree. We might want to do something like gre.mk, i.e., a  top-level make file that just pulls and builds the required CVS directories. However, although we've reduced a lot of the run-time dependencies on non-mail components, I think we have a lot of build-time dependencies. Some embedding clients handle this by just copying over the whole dist directory (basically, all the interface files) and then building the components they want. Or, you could have a makefile that runs the export phase on the whole tree, and then just does builds the components actually required at runtime. In any case, I believe you want to build from an actual mozilla tree. That will make it much easier to stay up to date. You can go on a branch for stability but I don't think you want to be making your own cvs tree from snapshots of the mozilla source.

How hard it would be to extract these segments would be useful.  For example, getting a useful e-mail library without javascript, database code, and gecko would be good.

Two out of three isn't bad We don't require javascript (unless you use SSL) or gecko right now.  I've discussed getting rid of some of the other components in a separate document, but I'd like to talk about the database code now. I realize that Chandler has its own database but I'm going to strongly recommend a co-existence strategy for the medium term while you get everything else up and running. Then you can think about getting rid of the local berkeley mailboxes and the .msf files. I'll consider each in turn:

Getting rid of Berkeley Mailbox Stores

This is relatively straightforward, but will require some sort of local mailbox store plugin architecture to be added to the mozilla mail backend. There are only a few places that we care what the format of the mailbox is -

•  appending messages to a local folder (e.g., pop3 get new mail, or move/copying messages to a local folder)
• fetching/streaming messages - we seek to the offset in the file of the message, and stream msgLength bytes
• changing flags on messages (delete, mark read, etc) that will survive blowing away the .msf file because of timestamp changes
  

For POP3 Get new mail, the natural way to change the storage model is by replacing the current nsIPop3Sink with your own. That would entail adding a contract id for nsIPop3Sink and Chandler registering its own handler for that contract id.

Reading messages happens in nsMailboxProtocol.cpp - a good way to substitute whatever data store Chandler uses would be at the transport or stream level. Currently we create a transport on a file input stream created on the berkeley mailbox file. Chandler would just have to create a stream on its data store. We don't currently have a mechanism for the input stream to be replaced but we could come up with one.

Storing flags persistently happens in nsMailDatabase.cpp - most likely this would just be skipped for Chandler, if the Chandler store didn't use Berkeley mailboxes which can get out of sync with the .msf files

Also, note that offline IMAP messages are stored in berkeley mailbox format, but the offline operations are stored in the .msf database.

Getting rid of .msf files

This will be hard. I'm not sure it's worthwhile unless having them causes some sort of problems. Not knowing what Chandler's plans are in the database area, I can see a couple possible ways of approaching this: writing a DB layer that provides the MDB interfaces, in which case the existing nsMsgDatabase code can just use it, or writing a DB that provides the nsIMsgDatabase and nsIDBFolderInfo interfaces, and leaving MDB out of it. Both would be a good deal of work, depending on what the underlying DB looks like. It would be very difficult to remove the uses of nsIMsgDatabase from the mail backend- it's pretty pervasive. If you wanted to avoid using nsIMsgDatabase, there wouldn't be a lot of code left that you could use (though the imap command handling and parsing doesn't directly refer to the db code). It's conceivable that you could provide a limited sub-set of nsIMsgDatabase functionality and stub out the rest - CreateNewHdr^?, GetMsgHdrForKey^?, and get and set property on an nsIMsgDBHdr would get you pretty far. This would be something we'd need to talk about down the road.