Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Mon Apr 3 22:00:07 UTC 2017
Joshua Cranmer 🐧 wrote on 03.04.2017 18:08:
> We've talked about rewriting Thunderbird for, oh, a decade or more
> now. We've had agreement on the direction these rewrites should take
> for at least 3 or 4 years (rkent was really one of the last hold-outs
> for using JS). But we've not really made any measurable progress on
> rewriting Thunderbird.
And you know why? Because nobody started. If we had started "a decade or
more" ago, we would be done since 5 years, would not be fighting Gecko
regressions today, and would be adding the features that the users today
are screaming for.
This is why I say: We have to make a bold move now. Now or never. If we
don't do it now, TB will survive another few years and then die together
with XUL and XPCOM and sleep in the same grave. And our users will be in
I want to give them a new home. One that feels like home for them.
> The problem with rewrites is that our codebase is very full-featured,
> and it's hard to replicate that functionality.
We won't be the first email client mostly in JS, and we won't even be
the first email rewrite under the Mozilla roof. I've been there for the
4.5 -> Seamonkey rewrite, as a lowly volunteer contributor.
Inaction is our biggest risk. The task is big, but doable. It's been
Please remember many of the features Thunderbird has are features for
the pre-2000 area. Like LDAP or Kerberos. Users today are asking for
completely different things, like syncing the address book with their
Android phone. I am not saying we should cut LDAP, given that there are
still people using it, but let's not forget that Thunderbird currently
does *not* have a lot of things that users desperately need.
> Things like S/MIME integration, downgrading text/html to text/plain,
> etc. were the ones that halted my work on JSMime.
None of these are a serious problem.
S/MIME would be an extension. It's currently also implemented as
extension in Thunderbird (mailnews/extensions/smime), just shipped with
core. I don't see why we couldn't do the same in a new Thunderbird.
I wrote the plaintext <-> HTML conversion and the downgrade etc. back
then. In fact, that would be much easier with a fresh design, in JS,
than with the code written originally 1993-something in C.
Of course, it needs to be designed properly. I cannot use the same
design that libmime currently uses. That's why it's so hard to replace
e.g. libmime. And that is also why a gradual rewrite fails.
> the DNS PGP/SMIME key lookup functionality
Huch? DNS? DNS is exactly one of the biggest problems in Gecko. I
desperately needed DNS SRV support for XMPP in JS, but couldn't get it
with Gecko. I needed it so desperately, I've even implemented patches
for Gecko to implement DNS SRC and TXT and others. That was 10 years
ago, with a lot of work. They were never reviewed. :-( 10 years later,
they are still rotting away in bugzilla. All that work was wasted.
For XMPP, I also needed to override the certificate check, to check
against a different hostname. Not possible in Gecko. I made patches, it
was in fact trivial to add to PSM/NSS. The patches were rejected,
basically with rationale "We don't need that". Patch is still sitting in
bugzilla somewhere, being ignored.
So, no, we don't have many features we would *need*, and that we could
normally easily implement. Gecko has been holding us back massively.
That's concrete experience.
> Now, the final and biggest problem with rewrites is that there's no
> backup plan if they fail
We do have a fallback. Thunderbird based on Gecko would continue to be
supported on the current level.
The 2 projects would run in parallel and independent of each other, they
share the project umbrella and the goal. The teams would be separate.
The Thunderbird-based-on-Gecko team would be free to pick any JS/HTML
implementations created for the new client and backport them to the old
client. I'm pretty sure we'd finally get the new AB this way.
The old Thunderbird could still get new features through the backports,
but the team for the future would not be held back by constraints from
the pre-2000 area. It could concentrate on advancing as quickly as
possible, with the goal of 99% feature parity with Thunderbird.
The gradual rewrite is what has failed. That's not just a possibility.
We tried and failed. As you said above, we wanted to do it since a long
time, and never succeeded. Thinking that we'll suddenly succeed now,
with less resources, is merely wishful thinking. And if that fails,
Thunderbird is dead for good, because XUL is going away eventually.
Sometimes, a picture says it best. Attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 62422 bytes
Desc: not available
More information about the tb-planning