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 
to ruin.
> 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 
Thunderbird.

> 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 
> eventually.

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.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170403/aabac34f/attachment.html>


More information about the tb-planning mailing list