<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Magnus Melin wrote on 4/5/17 9:14 AM:<br>
</div>
<blockquote type="cite"
cite="mid:165b88e4-31dc-e8d9-6752-77bcd4f2a05a@iki.fi">On 5.4.2017
03:09, Ben Bucksch wrote:
<br>
<blockquote type="cite">How did you develop JSMime? You first
developed it as a standalone component, then integrated it in
Thunderbird, didn't you? What I propose here would be doing the
same thing. How is that a multiplier?
<br>
</blockquote>
<br>
Implementing different features as components with modern design
is all good. What's not so good is that you seem to say actually
integrating those components into Thunderbird for real usage is a
secondary priority. It needs to be *the* priority, because that's
the only way you could get enough real world feedback.<br>
</blockquote>
<br>
I want to build a new desktop email client, based on web tech with a
modern code design, which imitates Thunderbird and eventually has
feature parity.<br>
<br>
I want to have real world usage!<br>
Year 1: I think it will take about 1 year until dogfood, meaning the
first most courageous people can try to use it.<br>
Year 2: After another year, I expect most people to be happy with
it, in terms of features. At that time, many users should migrate
voluntarily, because the new product is already better for them than
the old Thunderbird, even if it doesn't have all TB features, but it
has other cool features that TB can't do.<br>
Year 3: It will take a third year to achieve reasonable feature
parity with Thunderbird.<br>
<br>
Rome wasn't built in a day. But it was built. And new big cities
were built after Rome, too.<br>
<br>
So, the new components will form the new client. That is the
priority.<br>
<br>
If you believe in gradual rewrite of Thunderbird, then you can take
the new components and integrate them into the old Thunderbird. This
would effectively be more or less the same as you do when you
gradually rewrite Thunderbird without a new client: You first write
the new component, then integrate it into the live product. It's not
significantly more work than if you do only the rewrite.<br>
<br>
This approach has the following benefits:<br>
<ul>
<li>You're decoupling both tasks into separate teams. One team
writes the new components, with a clean, modern API, and another
team integrates it into Thunderbird. That allows each team to
focus on their tasks. They are very different tasks with
different skill sets.<br>
</li>
<li>If the rewrite fails to replace all of Thunderbird in time
before Gecko becomes unmaintainable, we at least have the new
client to fall back on.</li>
<li>The new components can have a clean code design in their APIs
and implementation. The new app is a coherent whole free of
legacy ideas. Concrete examples: XPCOM, communication between
modules using URLs, decoupling frontend, logic and
network/storage tiers.</li>
</ul>
<blockquote type="cite"
cite="mid:165b88e4-31dc-e8d9-6752-77bcd4f2a05a@iki.fi">
And you keep telling developing "a new email client in JS" in a
short time can be done, and have been done before. Well, there's a
reason people still prefer Thunderbird. You can develop something,
but what that something is...</blockquote>
<br>
I would probably be using Nylon N1 today, if it wasn't tied with a
server component. I don't need that many features, mostly UI speed,
tree views, filters, and multiple identities.<br>
<br>
Don't kill the past. But build the future at the same time.<br>
</body>
</html>