MailNews:Creating New Account Types

From MozillaWiki
Revision as of 01:27, 20 May 2008 by Jcranmer (talk | contribs) (Account types <- step 1)
Jump to navigation Jump to search
Warning signWarning: Some information here is specific to current trunk releases of Thunderbird and SeaMonkey, or, in some cases, rely on patches in the review process on Bugzilla.

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!