About this work

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

The following is the UML diagrams of (some) major components of Thunderbird. I started this work to document and share my understanding of Thunderbird architecture while working on a threading bug. This is a work in progress and I am planning to add more diagrams over time. I don't plan to cover everything, just important stuff.

I use only the basic elements of UML, and try to keep it simple as much as possible. I deliberately use some elements non-normative way, don't expect a perfect UML diagram. You can find the description of the common elements in the legend.

Also see Thunderbird Class Diagrams

Major Thunderbird Entities

Currently, Thunderbird supports four different incoming (IMAP, POP3, NNTP, RSS) and one outgoing messaging protocols (SMTP). Each incoming protocol provides its own implementation (i.e. imap protocol).

Each message source (url+logininfo+protocol) is represented by an Account entity, and all accounts are managed by AccountManager. Each account has an associated IncomingServer that is implemented by the corresponding account protocol.

Identity contains all the personal outgoing mail information for a given person. Although all account types can have multiple associated identities by design, RSS do not need this entity, as does any other account that does not interact with compose code.

AddressBook is the central repository of the user's contacts. Physical store of this entity is abook.mab file in the profile directory, and it is in Mork format. See Address Book Planning page for recent improvements.

Thunderbird uses a folder-based hierarchical representation to organize messages. Folder is the logical entity that contains message contents belong to the same hierarchical level. Message content consists of message headers and message body including attachments. These two entities are stored in different physical stores to improve the system performance. Every Account has a root folder, which may have several subfolders (each potentially with their own subfolders, ad infinitum) which are actual folders on the hosting operating system.

Database entity represents the physical store of message. Each "Folder" (in the Thunderbird sense) which can contain messages is represented by two files (in the OS sense): the messages themselves (headers and bodies, in human-readable mbox format) are in one file ("folder" name without extension), while a second file (msf file in Mork format) indexes them for fast access to a given message.

Core Components

• Address Book

TBD

• Message Incoming Server
  • interface
  • Implementation
• Account Manager
  • interface
  • implementation
• Message Folder
  • interface
  • Implementation: Message Database Folder
• Message Database
  • interface
  • implementation
    • NewsDatabase, MailDatabase, ImapMailDatabase
• Searching
  • Static View
  • Sequence diagram for offline search
  • Sequence diagram for online search

Protocol Implementation

• IMAP
  • Sequence diagrams
    • System Startup
    • System Shutdown
    • 'Get Mail' button clicked
    • OnBiffTimer event
    • Connection Error case
    • Message Delete
    • New Message
  • Class diagrams
    • nsIImapIncomingServer interface
    • nsImapIncomingServer class
    • nsIImapProtocol interface
    • nsImapProtocol class

• POP3
  • nsPop3IncomingServer
  • nsIPop3Protocol
  • nsIPop3IncomingServer

• NNTP
  • NNTP Implementation Notes

• RSS