MailNews:Creating New Account Types
This page aims to provide a detailed guide on creating new account types from extensions for Thunderbird and SeaMonkey. This is still a work in progress, heavily dependent on my (jcranmer's) personal tree, where some critical components are merely patches in my tree and on bugzilla (where the latter may not be the most up-to-date).
The Account Manager
The best I can describe the account manager is that it is a hydra of components, managing several slightly different, but distinct, components. Primarily, these are servers, accounts, and identities. Folders, messages, message headers, databases, URLs, message DB views, the folder cache, and even more end up becoming part of this mess of topics to cover, the full scope of which is beyond the scope of this article. Needless to say, I will provide a sufficient overview to allow you to create a new account type.
For a diagram-based view of what is going on, see emre's diagrams on the subject. For other views, I invite you to run make documentation on the mozilla codebase to generate doxygen graphs and pages for the key components. This documentation can also be accessed at db48x's site, although I will warn you that he is using the experimental SVG output for doxygen which is quite obviously not quite production-ready.
Step 1: Account types
TODO: nsIMsgProtocolInfo seems to fall through the cracks of doxygen; fix that
TODO: Investigate where nsIMsgProtocolInfo is used
The first thing to do when designing a new account type is to pick an internal name. This name should probably consist of the typical characters: alphanumerics, underscores, and dashes; this name will be used heavily as URI schemes and as portions of CIDs. For sake of simplicity, let's assume that the new account type is "acct" (don't actually pick this).
Defining account types requires that you implement a few interfaces. The most important ones are nsIMsgProtocolInfo, and nsIMsgIncomingServer, while other interfaces are important if you do crazier stuff, which you most likely will.
nsIMsgProtocolInfo
Our first interface to implement is nsIMsgProtocolInfo, which defines basic parameters of the account type. A fair amount appears to be special casing for local folders. The contract ID is important; set it to be @mozilla.org/messenger/protocol/info;1?type=acct in our current example. Assuming you can generate the XPCOM overhead yourself, the following is an example of what to use:
TODO: Finish the account info portion. Some things have unanswered questions.
accountInfo.prototype = {
get defaultLocalPath() {},
set defaultLocalPath(path) {},
get serverIID() {},
getDefaultServerPort : function (isSecure) {
return isSecure ? 8080 : 80;
},
// True if you need a username
get requiresUsername() {return false;},
// True if the pretty name should be the email address.
get preflightPrettyNameWithEmailAddress() {return false;},
// True if you can delete this account type
get canDelete() {return true;},
get canLoginAtStartup() {return true;},
// True if you can duplicate this account type
get canDuplicate() {return true;},
// Do we have an "inbox" for this account type?
get canGetMessages() {return false;},
// Can we use junk controls on these messages?
get canGetIncomingMessages() {return false;},
// Can we request new message notifications ("biff")?
get defaultDoBiff() {return false;},
get showComposeMsgLink() {return false;},
get specialFoldersDeletionAllowed() {return false;}
};
All of the options--except the first three--are simple true/false boolean attributes that ask whether or not an account can do specific things. Full, up-to-date documentation is available at the IDL file; note that, in a few cases, the attribute name is a poor guideline for what it actually does.
nsIMsgIncomingServer
TODO: Write me! Now!
Step 2: Account Wizard Overlays
TODO: Write me! Now!