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

Ben Bucksch ben.bucksch at
Tue Apr 11 16:26:27 UTC 2017

Joshua Cranmer 🐧 wrote on 11.04.2017 04:57:
> On 4/10/2017 8:42 PM, Ben Bucksch wrote:
>> I'm not sure what you mean. But I don't think that when we rewrite, 
>> we should first complete 100% of the Thunderbird IMAP features before 
>> we start with address book, or vise versa. Rather, I subscribe to the 
>> MVP (Minimum viable product) idea. I want to first have a functional, 
>> but minimal and simple email client using only web techs (plus socket 
>> and file I/O of course, but still pure JS). That includes all of 
>> IMAP, POP3, AB etc., but not at the level of TB yet, but just the 
>> basics to read and send mail. Then, we build it out to be a good (not 
>> simple) email client, so that 80% of the users are happy with it. 
>> Then, finally, we build all the remaining TB features that the 
>> remaining 19% need. That's the idea of MVP.
> I agree that basic implementations of "everything" comes first. Beyond 
> that, well, it's best to explain with a hypothetical. Suppose we 
> decided that LDAP and QRESYNC support were both necessary final 
> features but not earlier mandatory features, and suppose that LDAP 
> were the last feature not found in the new address book. I'm saying 
> that we should prioritize finishing the LDAP implementation (via FFI 
> to OpenLDAP, say) over implementing QRESYNC. Outside of that specific 
> kind of situation, there isn't much difference in various approaches, 
> and it's hard to say that sort of situation will even come up in the 
> first place. So I'm not going to push very hard on this.

So, you're saying we should prioritize existing features (LDAP) over new 
features (QRESYNC) that Thunderbird-Gecko does not have? Yes, I 
generally agree on that. More specifically, the fact That Thunderbird 
currently has that feature makes that feature rise considerably in the 
feature list. I wouldn't make this an absolute, though. I think that 
some way to sync the address book with mobile phones is more important 
than LDAP, these days.

Things like prioritization are decisions that are best made numerically. 
You count number of users who use the feature in current Thunderbird, or 
you let people vote what they want and why, or things like that. 
Essentially, you make sure you really know what people need, and why. 
And then, on top of that, existing features get certain bonus points 
over new features, to make sure we cover the old Thunderbird feature set.

>>> This also means that whatever platform support library you have 
>>> would include support for xpcshell/xpconnect/whatever else is being 
>>> used by Gecko as a base layer.

> The problem with JS is that it doesn't have much in the way of the 
> standard library. A TCP socket, for example, is handled very 
> differently in node.js, in Chromium extensions, in XPCOM, in the B2G 
> bindings, etc. At some point, you need a library that presents a 
> common API for all the platforms to its different users

Ah, I see what you mean. Yes, I agree. For example, for my IMAP and POP3 
implementations in JS (written by me for a XUL extension), I first wrote 
a small Socket.js that abstracts the XPCOM API. It's not very big, and 
it's simpler than the XPCOM API. When I port things to node.js, I have 
to re-implement this Socket.js. But the IMAP and POP3 implementations 
have no dependency on XPCOM and should hopefully then work after 
porting. I'm expecting a day of work for this. In fact, that's the one 
of the things I wanted to do this week or next week, if I can find the 
time, so we'll see.

Luckily, JS covers a lot already. I've identified the following parts 
that are not well standardized:
* Module system (I've spent the day yesterday to convert JSM to 
npm-style require())
* Interprocess communication
* File system access (in node.js: require("fs"))
* TCP Sockets

FS and Sockets are rather easy, because relatively easy to abstract. 
Module system is harder, but require() is reasonable.

The biggest problem in practice is the communication between UI and 
backend (IPC). That can be vastly different, and can break the neck of 
the project. Concretely, this is why I abandoned my port from XUL 
extension to Jetpack. Luckily, that appears to be easy in Electron, with 
the shared |global| object. I have yet to really test it in practice, 
but it appears to work really nicely.

> the JS environment of Thunderbird is included as one of the platforms 
> in this list

Yes, XULRunner vs. Electron vs. Cordova is the "platform" for TB-Next, 
I am hoping to keep it reasonably platform-abstracted, without too much 
of a compat layer. Nothing like NSPR again, please! Luckily, JS gives us 
most of what we need (basic types, etc.)

I will use the latest and greatest JS version, though. I really want to 
use "=>" functions, and |class| if possible.

Too bad modules are not there yet.

> (In particular, how to handle ES6 modules versus require.js, etc. is 
> not something I can recommend a solution to at this moment).

hihi! ditto! I was just asking myself the very same question this week. 
Comforting to hear that you're facing the same dilemma. I've picked 
require() for now, and it seems to work reasonably well (once I figured 
out how to initialize "app-module-path").

> The original proposal gave the impression that Thunderbird development 
> was to be unfunded, and certainly much of my wording was meant to 
> focus on overturning that viewpoint.

Sorry, I worded it too drastically. I mean we should maintain status quo 
for Thunderbird based on Gecko.

The danger to Thunderbird-on-Gecko is not this project, but increasing 
breakage caused by Gecko, which will soon have unsustainable levels. 
That's why I propose this project as solution.

> Which means we're in total agreement here.


> So starting out with descriptors like "next-generation" or 
> "experimental" or "incubator" ... probably work better.

OK. I'll go with "next-generation".

Greetings to Jean Luc Picard! :)


More information about the tb-planning mailing list