Rewrites in mailnews

For those who haven't kept up with mailnews news, my main work-in-progress is, to use jminta's terminology, kill-mork. Kill-mork is, in short, the RFE to replace all usages of mork in mailnews to use MozStorage, starting with the address book (legacy conversion being ignored here). I started this job around mid-December, and now it is mid-January. What do I have to show for a month of work? On the face of it, not much: no patch, not even my local build, requires the usage of MozStorage. But a lot has gone on in relation to this task that is not obvious.

Ultimately, the main goal of kill-mork is not to eradicate, excluding legacy, the usage of mork. If it was, I would have had at least preliminary work on address book conversion by now. No, the main goal is to make the design of address book amenable to the creation of different backends. Look at it like this: before one moves to a different house, one cleans the house to find what should and shouldn't be carried over to the new house. That's what has been happening in address book, the house-cleaning.

There exists another, larger task after kill-mork: kill-RDF. Mailnews uses RDF internally in the address book and in the account manager because RDF was The Next Big Thing™. It never really caught on, and has become a source of headaches and a barrier to comprehension ever since. This is actually much larger a task since the account manager has multiple implementation, whereas there is only one implementation of msgdb and address book to date. But kill-RDF's cleaning counterpart is also more important: the account manager interfaces.

To see that the account manager needs to be changed, try adding a new account. Anyways, this is my proposal for a new account manager. The account manager acts as a singleton interface, allowing simple access points for the creation of a certain type of account, deletion of one, and getting accounts (all, all of type, one given uid, ???). Each account has a type, like imap, news, or local. Accounts have at most one associated server (a local account might not have one, for example), and have multiple folders. Each folder has a format (type is a better name, but it's already being used in a different context). Imagining if a calendar-type account existed, its folders would have a local calendar format and an ICS format; a hypothetical address book account could have an MDB, LDAP, or SQLite format folder. Example:

var account = acctmgr.createAccount("news"); account.serverURI = "news.example.com:119"; // Subscribe to certain newsgroups // This creates an SQL-db online folder account.addFolder("test.example", "sql"); // An offline folder with a file-per-message format with an SQLite-format db. account.addFolder("test.example2", "offline-folder-sql"); // A folder that is not a newsgroup using an offline mbox format with an mdb. account.addFolder("test.does.not.exist", "offline-mbox-mdb"); // This cannot work: the account cannot create an online folder for a non-existent newsgroup //account.addFolder("test.does.not.exist", "sql"); // ... var serverIterator = acctmgr.accountsOfType("news"); // ... Search news server for one with the "test.example" group