Proposal to start a new implementation of Thunderbird based on web technologies
R Kent James
kent at caspia.com
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
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