Proposal to start a new implementation of Thunderbird based on web technologies
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Mon Apr 10 16:42:20 UTC 2017
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.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning