<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/3/2017 5:00 PM, Ben Bucksch wrote:<br>
</div>
<blockquote type="cite"
cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">Joshua
Cranmer 🐧 wrote on 03.04.2017 18:08:
<br>
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<blockquote type="cite"
cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
Inaction is our biggest risk. The task is big, but doable. It's
been done before.
<br>
</blockquote>
<br>
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>I have put more work into rewriting Thunderbird in the
past decade than you or probably anyone else on this thread has</i>.
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). <b>That</b> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
We do have a fallback. Thunderbird based on Gecko would continue
to be supported on the current level.
<br>
</blockquote>
<br>
That is not a backup plan, especially not if XUL Gecko dying is one
of the main motivations for embarking on this project.<br>
<br>
<blockquote type="cite"
cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
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.<br>
</blockquote>
<br>
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:<br>
<br>
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.<br>
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.<br>
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.<br>
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).<br>
<br>
<blockquote type="cite"
cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
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.
<br>
</blockquote>
<br>
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).<br>
<br>
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. <b>BUT</b> 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.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>