From MozillaWiki
Jump to: navigation, search

The name "Thunderbird: Next Generation" is a homage to my favorite TV series Star Trek: Next Generation, which took a great thing, and made it even better. Same concept, new ideas, and much better. Several decades later.

Thunderbird is now over 20 old. The beginnings go back to 1995, with the Mail component in Netscape 2.0. Then came Netscape Communicator 4.5, by another team. 1999-2000, it was turned into Mozilla Seamonkey, then into Thunderbird. The change to Mozilla with XUL and XPCOM was big, but still kept a lot of the backend code. On top of all that are a few decades of hacks.

It's time for a refreshment, using a clean architecture and using a clear separation between model and view, and a thin view, to allow for easy changes to the view or even completely separate views, e.g. for mobile. Architecturally, change observers will help a lot to keep the components decoupled.

What's really making this change required, though, is that the Mozilla platform moves away from XUL and XPCOM towards HTML and Servo. Both XUL and XPCOM are base technologies that Thunderbird is written in or that define core parts of it. The Thunderbird project already uses a good part of its development effort just keeping up with Mozilla changes, and this effort is going to increase significantly in the near future (Nov 2017) when XUL extensions are dis commissioned. Mozilla made this drastic move not to deliberately kill a community, but to allow them to make large changes to the platform. These very changes are going to affect Thunderbird massively, being the largest XUL and XPCOM application ever written, even bigger than Firefox itself.

This means that large parts of the codebase have to be rewritten anyway, in the mid-term to near future. The TB:NG project proposes to use this opportunity to also create clear component separation and clean API that make it easy to learn the codebase and easy to make changes to it. A good extension API surface and more stable extensions would be a side effect of a good internal API.


  * Storage
  * Model (read first)
  * Services
  * View
* Technical cross-application APIs
  * Collections
  * Error handling
  * Async functions