Monday, January 21, 2008

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

3 comments:

DigDug said...

If you're really going to do this, can you make sure that you take into account things like social web services and IM accounts. Who knows if Facebook will survive long, but right now it would be nice to get my messages (or better yet, messages from all its folders/applications) right through my mail client, and to be able to tie/sync a friends list with my addressbook.

Shawn Wilsher said...

It'd also be a really good idea to allow the use of system address books. I know OS X has a system address book, and I think Vista does as well. Password manager is working towards allowing different data storage containers for this specific reason (like Keychain on OS X).

zooplah said...

I never really knew what Mork was (other than he was from Ork and played by Robin Williams). It's good that you're working on making it more extensible and pluggable.

One thing, however, is I've never gotten Mozilla's logic in using RDF for everything. Back in the 90s, I thought "What possible use is this? Maybe I'll find out when it's used." But as far as I can tell, it's really not useful much at all; it's just complex, bloated, and recursive. I'm still at a loss about why the RSS 1.0 guys thought it would be a good idea to make the language RDF-based (the only good thing about it, in my opinion, was rdf:about on <channel>, which was handy if you used an RSS reader as a helper application and wanted to subscribe to the feed).