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

[Ben Bucksch]

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 
the winds.

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 
done before.

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.

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boat-weight.jpg
Type: image/jpeg
Size: 62422 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170404/b97e34f7/attachment-0001.jpg>