Future Planning: Thunderbird as a Web App
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Fri Sep 18 00:56:27 UTC 2015
CC'ing asuth, who I think absolutely has some information worth conveying.
On 9/17/2015 5:03 PM, Kent James wrote:
> As we are discussing our future, both in relation to radical changes
> expected in the Mozilla platform, and our need to express where we are
> going to potential partners and donors, we need to discuss and agree
> on some big-picture issues. One of those was end-to-end encryption
> that we discussed recently. I want to discuss here our future
> platform, and how it related to users and their needs.
> tl;dr Thunderbird over the next 3 years needs to convert to being a
> HTML5. (web app does not imply cloud-based, only that the underlying
> platform is js/html).
There is one point of caution I want to make. The JS ecosystem is still
rather fragmented. An example of all of the different execution
* Mozilla XPCOM/Chrome JS
* B2G-style JS apps
* Chrome-style JS apps (/ web extensions?)
* JS apps in places like Windows RT (I don't follow mobile enough to
know all the fragmentation)
* Pure HTML5 webapps (including aspirational specifications)
Even basic APIs can be radically different between them--for example,
every single environment I've listed has a different API for reading
from a socket. There is a slow convergence between these different APIs,
but it's on the order of a few years. And, unfortunately, a part of the
missing API is rather fundamental concepts: node.js only started
embracing Promises with version 4, released this past month (!), and
Streams are still nowhere in sight.
There is also some good news in that JS tooling infrastructure is now
racing to properly support es6. I did grab code coverage of my latest
es6 codebase (an UTS #46 mapping tool, so I can feed that into JSMime),
and I'll probably poke at making it work with JSMime when I get time for
> There are two independent but both equally critical reasons why we
> need to go this direction.
> First, the Mozilla platform itself has no long-term commitment to
> being available as a general-purpose development environment to run
> non-browser software, other than as a web app. At the same time, they
> are doing amazing innovations to allow more and more functionality
> traditionally associated with native clients to run under the "Web as
> a Platform" meaning the HTML5/ES6 stack. Really in the long run we
> will either have to fork the Mozilla platform and maintain it
> ourselves as an email development environment, or go with the flow and
> convert. Let's convert.
> Second, more and more users are using a variety of platforms,
> including not only our traditional desktop environments but also
> Android and iOS (and other mobile OSes hoping to join them). I'm
> writing this message using Thunderbird on a Microsoft Surface 3
> Tablet, which can now run traditional Windows applications such as
> Thunderbird. But we can't expect most of our users to buy a tablet
> from a second-tier operating system, merely to be able to run
> Thunderbird (as I did). In the last 24 hours, I have accessed my email
> using 4 different devices (Android phone and tablet, Windows desktop
> and tablet). Only 2 of those devices can run Thunderbird. We need to
> have a serious mobile story. Starting from the existing
> forward-thinking Mozilla web environment, we should be in an excellent
> position to convert our existing code to ES6-js/HTML5, and that is the
> best long-term way to support our users on the full range of platforms
> that they expect to use.
> Last year, jcranmer introduced JsMime for some of the mime-related
> processing. This year, he is specing a Js database. I am working on
> JsAccount that will allow us to create new mailnews accounts and
> associated objects (server, folder, URL, protocol, etc.) using js and
> interoperate with our existing code. Although initially aimed at new
> account types, JsAccount will eventually make it straightforward to
> incrementally convert all of those core objects from C++ to
I actually have more JS projects I've been working on:
1. JSMime (<https://github.com/mozilla-comm/jsmime>)
2. Emailsasl (a SASL client library)
3. Email-socket (abstracting away the combination text control/binary
data nature of NNTP/SMTP/POP/IMAP) (not public yet, since I haven't
gotten very far with it).
4. UTS #46 support (<https://github.com/jcranmer/idna-uts46>)
Something that you'll notice is that I've been also making sure, at
least for the low level code, that I can work simultaneously with
node.js tests. I didn't do it for JSMime because node.js was in a really
horribly place several years ago, and I haven't had the time to go back
and do the fixes necessary to get it working.
> Looking to a rough long-term schedule, I see future versions of
> Thunderbird looking like this:
> 38 (Avocet), 45 (3/2016 Bunting), 52 (01/2017 Cormorant?): Traditional
> XUL/C++ app
> 59 (09/2017 Dunlin?) Last and traditional XUL/C++ release. By this
> date, a reasonable possibility is that the Mozilla platform will no
> longer be usable for non-browser XUL-based development. This version
> of Thunderbird, in that case, would need to ship on a fork of Mozilla
> from the point where XUL-based development becomes untenable. This
> will also be our last major XUL-based release, and we will not attempt
> to keep current with the new non-XUL Mozilla platform. It would also
> be useful to ship a stripped-down version of Thunderbird as a web app
> with this release.
> 07/2018 Egret? (no point in matching release numbers to Gecko
> anymore): Thunderbird ships a full-version web app.
> I don't see what choice we reasonably have, given the announced
> changes in the Mozilla platform. We should view this as an opportunity
> to both get out from the current Mozilla regression-driven
> development, to being able to focus on our own issues. Hoping we can
> adapt to changes in the Mozilla platform, with no commitment from
> Mozilla that they will try to make that easy, is an enormous risk with
> little upside for us.
I think it is absolutely vital to share maintenance work of "low-level"
protocol code with Gaia email or other components, by which I mean:
* IMAP, POP, SMTP, NNTP (not that Gaia is likely to do anything with
NNTP, but they all ought to share the same email-socket layer).
* MIME (+ TNEF decoding, S/MIME, PGP, I expect)
* vCard / CardDAV support
* iCal / CalDAV support
* Chat protocols
* Sieve / managesieve
I do want to counter that I'm not entirely sure the current state of
affairs is ready for us to go whole-hog on JS conversion. ES6 modules,
in particular, are a big change that is going to have lots of
repercussions, but no engines have fully implemented it yet (look for Q4
2015 or Q1 2016?), and some aspects of the standardization process are
in a holding pattern (e.g., HTML imports) until after people get more
experienced with them.
That's not to say we shouldn't move forward: rewriting some libraries in
JS (e.g., JSMime usage) is probably still worthwhile, and I think we can
get agreement now that new API design should be focused on ease of use
for JS consumers, with the XPIDL interface for C++ use being a
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning