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

R Kent James kent at
Fri Mar 24 18:41:48 UTC 2017

I'm generally in agreement with what you have said (and I think others 
are as well), with the possible exception of whether to do the 
transition as a complete replacement, or as a gradual conversion of the 
existing codebase.

I've been working on the gradual replacement approach for the last few 
years, in C++->JS conversion. The JsAccount technology, which is now in 
Thunderbird 52, allows in theory the main back-end account modules 
(IMAP, POP3, SMTP, NNTP, RSS) to be replaced by JS equivalents. I know 
how hard it is to trace through the muck of existing implementations to 
try to figure things like, how do I get the UI to actually show the 
change I just did without having to do a restart or resync? And now 
Ehsan says things like "oh by the way, we're not going to allow protocol 
handler newURI in the future written in JS" and now the whole scheme 
collapses, and JsAccount is going to have to adapt.

But at the same time, many, many attempts at rewrites fail. The most 
valuable asset that Thunderbird has is our userbase, which in spite of 
lousy communications and "Thunderbird is Dead", continues to slowly 
grow. ADI on March 6 was 10,258,971 which I believe is a new high, 
though we have been at just over 10,000,000 now for a couple of years so 
growth is very slow. It is absolutely critical that we bring our users 
along with us, and I have serious doubts about whether a sudden change 
to a new UI and program is something they would follow. Read "The 
Phoenix Project" for a classic description of the challenges and false 
hopes of the Amazing Rewrite while the core technology collapses around you.

So I have mixed feelings.

But I have plans. I am specifically looking at the Address Book rewrite 
as an opportunity to explore alternate approaches. The next step is to 
come up with a very simple Contact Manager UI (possibly using the New 
Zealand class project as a base), and exploring how to make that work in 
a variety of target environments. That would include at least 1) 
embedded in existing Thunderbird as an addon, 2) as a standalone 
Electron App, 3) as a traditional website, and 4) as a Progressive Web 
App. There are other possibilities as well, such as 5) using Myk Melez' 
qbrt Gecko-based desktop, 6) .NET, 7) React-native for mobile.

I also am aware that one of the most challenging platforms is likely to 
be 1) embedded in existing Thunderbird as an addon. I know the existing 
nsIAB* interfaces pretty well, and interfacing with them at a low level 
(as nsIAbDirectory implementations) is extremely challenging. 
Practically it is impossible, as any reasonable future API for 
Thunderbird contacts would be async, while the existing API is fully 
sync with a hidden async implementation used in LDAP and relying on UI 
notifications. So bolting onto Thunderbird is only going to be possible 
by rewriting existing Thunderbird to support an async Contacts interface.

You (Ben) are saying that rewriting Thunderbird to support a new Address 
Book implementation is not worth the effort, instead we should hold 
back, and wait some years before we make this available to our users. I 
have serious doubts about that approach. But at the same time, this 
Thunderbird adaption is not a project I would want to give to my 
students, so who is going to do it?

No easy answers, but I hope to make progress in the next year, and I 
hope this will be my major focus.


More information about the tb-planning mailing list