Proposal to start a new implementation of Thunderbird based on web technologies

[Joshua Cranmer 🐧]

On 4/9/2017 3:01 PM, opto at optosolar.com wrote:
> As much as a new start may make sense from a programming point of view, from a user's perspective, I just want to point out that this will kill nearly all addons/extensions.
>
> I am confident that members of this list may update their extensions, but most other extensions will be lost, especially if not only XUL is gone, but if the API totally changes.
>
> Also, we might be facing 3 years of no new features for TB, but also 3 years of no new extensions for TB. Can there be any mechanism that extensions might be reused after rewriting? Or having need of minimal changes only?

Most add-ons today rely on infrastructure that Mozilla has expressed 
interest in killing, namely XPCOM, XUL, and XPConnect. The sad truth is 
that Thunderbird has no real resources to maintain these technologies 
itself: XUL is deeply baked into the display engine, and XPConnect 
relies on a very fickle JS engine API and has serious design flaws baked 
into it (XPCOM is essentially a giant hashtable, with some mild C/C++ 
reflection and a few assorted helper ADTs--it basically requires so 
little maintenance that large portions of it effectively haven't been 
touched for a decade). It's not really in our hands to decide whether 
these extensions can be reused, although we do have some measure of 
control over how painful it would be transition them to a new system.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist