Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Tue Apr 4 20:05:23 UTC 2017
Joshua Cranmer 🐧 wrote on 04.04.2017 02:58:
> On 4/3/2017 5:00 PM, Ben Bucksch wrote:
>> 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.
> It is a lie to say that no one started.
work wonderfully. So, it's definitely technically feasible. However,
they are not a replacement for Thunderbird, because they are based on
custom servers, and they do not even try to have the features that
Thunderbird has. That's not because it's impossible - they have other
difficult features, like PGP or telephone integration -, but because it
was not their goal. They just had a different user group in mind.
I meant a full email client, to replace Thunderbird. The Thunderbird
project has never seriously tried that.
I specifically excluded attempts to gradually rewrite, by replacing
certain components of the old Thunderbird. That was my whole point. We
have tried that, indeed, and it hasn't gotten us anywhere. If it had
worked, we would be finished by now, with a renewed Thunderbird. After
"a decade", we're very far from done. We simply don't have another 5 years.
> There have been at least two projects with the clear intention of
> rewriting major portions of Thunderbird that produced concrete results
> yet have failed to come to fruition (Ensemble and JSMime)
I know your work around JSMime, and I appreciate and respect your work.
> what concerns me: that you're going to hit a roadbump, and everything
> is going to go wrong, and there is going to be no Plan B.
There is a plan B. I am not proposing to stop Thunderbird based on
Gecko. It will continue until the replacement is ready. Everybody has
the option to switch at the moment they feel the replacement is better
for them than the old Thunderbird. That will be a different moment for
At the end, we will make a specific effort to migrate the features that
the remaining users need.
Also, Thunderbird-on-Gecko can backport the new developments. I also
described that. That's another risk mitigation.
That means there *are* 2 plans. There is a Plan B.
If you gradually rewrite, *then* you don't have a plan B. The
integration of new components into old codebase is hard. If the rewrite
fails, or does not finish in time (same thing), you are dead.
> force [the replacement] down everyone's throats
I don't think that's a fair argument. You also force your rewritten
components "down the throat of everyone" (to use your own language),
even in the old client. What, if I don't like the replacement part or
how it works? Same thing.
> for example, that you have problems with unacceptable performance on
> message display, and that this resists all attempts to bring it to the
> performance level of existing Thunderbird code for years.
Please don't pretend that Thunderbird is perfect. Here, my Thunderbird
keeps freezing for 3-5 seconds every 15-30 seconds. I have one of the
fastest desktop machiens you can buy. It's like that since years, but
it's getting worse. Do you any idea how disruptive this is? I've filed
bugs about this, posted all information and symptoms I have there,
without any action. This makes me want to trash Thunderbird. And that's
saying something, because I've put a lot of my time into it.
> What do you do?
Fix it. There are enough email clients built in JS to prove that it's
> This is the sort of risk that concerns me deeply, and the best way to
> mitigate is to minimize the criticality of delivering any one
> individual feature.
You're welcome to backport individual features of the new implementation
to the old Thunderbird.
> Proposing a complete rewrite and not seeking gradual uplifiting is
> exactly the opposite of that strategy.
No, it's not. It's just 2 efforts running in parallel: Creating the new
app, with a clean code design, and backporting the new components to old
Thunderbird. And that can be done in separate teams. You do effectively
still do a gradual rewrite of the old Thunderbird.
You just a) share the load and b) don't compromise the new design with
old APIs and c) if the integration with old Thunderbird does not work
out, you still have a working result: the new version.
I am so insistent, because I'm convinced that the gradual rewrite will
not finish in time. It will be late by years, if it ever finishes at
all. If project history is any indication, I think it will outright
fail. So, what I propose is in fact risk mitigation.
(The other reason is that the Thunderbird code design is 20 years old
and just not fit for today, and a gradual rewrite would keep the overall
All our attempts of something new have always failed, because we held on
too much on old code and old thinking. The task itself is doable. It's
just extremely hard within the constraints of the old thing.
> 3. I am not proposing to maintain the current APIs.
How did that work out for JsMime? See what I mean?
More information about the tb-planning