Pluggability

Pluggability is an area where there is often still much to explore. A fair amount of the mailnews work involves this area. The address book rewrite (bug 413260) is designed primarily to refactor the interfaces to make adding the SQLite backend (bug 382876) easier: a fair amount of code assumes mork than is healthy. My current WIPs have limited this code to portions within addrbook, palmsync, and parts of import (i.e., not much at all). Not only is the SQLite backend going to benefit, but LDAP does in part (although I have not implemented enough of its methods), and probably Outlook and OS X directories as well.

Another large area where mailnews could use a pluggable interface is storage. In my last post, I discussed my thoughts on storage. To clarify one point: I am not against pluggable storage APIs or even implementations of most of those presented; it is just my opinion that mbox should probably be the default in lieu of a better choice.

A third area is the account manager. As far as I can tell, the only thing everyone can agree upon is that it does not work well as it stands. Try creating a new account type and you'll see what I mean. Killing RDF will help this in part, but the current consensus is to hold off a rewrite in this area until post-Thunderbird 3.

To keep this post short, I'll omit details in the other areas where we could use pluggability. The view pane could use it at least in part (see this site for more information). Supporting synchronization with mobile devices (several bugs exist here) would need one, if we want to go beyond palmsync.