Proposal to start a new implementation of Thunderbird based on web technologies
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Tue Apr 4 00:58:06 UTC 2017
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. 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), and depending on how and what you want
to count, probably another 4 or 5 that didn't produce actionable results
or were not clearly intended to replace existing code (e.g., Raindrop,
Gloda). If you want to make progress, you need to learn from mistakes.
Denying the existence of those mistakes will only lead you on the path
> Inaction is our biggest risk. The task is big, but doable. It's been
> done before.
Inaction is not the biggest risk. I am not proposing inaction. I am not
objecting to the idea of rewriting most/all of Thunderbird. Hell, /I
have put more work into rewriting Thunderbird in the past decade than
you or probably anyone else on this thread has/. That's not the problem
with your proposal. The problem is that you're suggesting... well,
basically inaction (on a feature level) while you go off and work on a
separate project, hopefully to force it down everyone's throats when
it's done. And arguing that it will be so wonderful and timely that
there's not going to be any problems forcing people to switch (I am
aware that this is probably a gross caricature of what you're
proposing). *That* is 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.
The biggest risk is that one snag derails the entire project. Suppose,
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. (This is not
unrealistic: this is exactly what happened to ical.js). What do you do?
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. Proposing a complete rewrite and not seeking gradual uplifiting
is exactly the opposite of that strategy.
I will reiterate, again, to take a look at how Mozilla is integrating
Servo into Gecko. Note what they are doing (moving things piecemeal) and
what they are not doing (halting development of Gecko while they
implement Servo). This is a project with far more available resources,
both absolutely and in proportion to its size and userbase, than
> We do have a fallback. Thunderbird based on Gecko would continue to be
> supported on the current level.
That is not a backup plan, especially not if XUL Gecko dying is one of
the main motivations for embarking on this project.
> 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.
If you expect the end-goal to be "TB users get
force^H^H^H^H^Hauto-upgraded to new product" and expect that to go
without serious objection, you are sorely mistaken. There needs to be
communication and liasons between the two teams if you want it to go
smoothly. Some more points:
1. Realistically, you're proposing a skeleton maintenance team for TB,
more or less what we've had for the past 5 years or so. This team will
likely have to spend so much of its time keeping TB building that they
are unlikely to have much time or ability to port new components to it.
2. Thunderbird has 15+M users, your new product will have maybe
hundreds. Email is rife with buggy implementations and has no general
conformance testsuite, so you're not going to find problems until you
get actual users with their weird edge cases. Your developers should be
jumping at the chance to have their work in Thunderbird.
3. I am not proposing to maintain the current APIs. Nor am I proposing
to maintain the current feature set. What I am proposing is that the
idea of "how can we get this into Thunderbird without getting all the
unfinished stuff" should be a first-level concern. The answer might be
that it's impossible--transitioning the database API is perhaps
infeasible, and as a result, migrating anything that relies on the
database wouldn't be possible. On the other hand, structuring your
nntpclient implementation to roughly correspond to the methods on
nsINntpService does seem like a good idea.
4. There is a lot of great technical knowledge stored in the TB
repository (in a hard-to-read form, sure). It's easy to make assumptions
based on specifications that aren't true in practice (e.g., the charset
of message headers), and it's all to easy to make a design that's
hostile to the changes needed to support those assumptions (this,
broadly, is the failure of libmime).
> 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
The glaring failures we have are not that the rewrites failed. We could
have had CardDAV 5 years ago, but we decided to have it implemented in
Ensemble instead. I could have finished EAI support years ago, instead I
made it contingent on JSMime. Those rewrites failed ultimately due to
lack of manpower, and not because they were trying to maintain current
APIs (Ensemble didn't try to, JSMime did seek to maintain compatibility
in the interim but wasn't designed on it).
I keep going back to Servo, but it's a good model IMO. By all means,
incubate implementations in a product outside of Thunderbird. Feel free
to experiment on alternative methodologies without worrying about how
exactly to squeeze it into Thunderbird. *BUT* when you draw up the
roadmaps, when you write out the work plans, when you farm out the
coding tasks, have bullet points that ask "What can we deliver to
Thunderbird?" Servo is not the replacement for Firefox, it is the
product in which improvements to Firefox are incubated.
Thunderbird and DXR developer
Source code archæologist
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning