Proposal to start a new implementation of Thunderbird based on web technologies

[Ben Bucksch]

Magnus Melin wrote on 4/5/17 9:14 AM:
> On 5.4.2017 03:09, Ben Bucksch wrote:
>> 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?
>
> 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.

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.

I want to have real world usage!
Year 1: I think it will take about 1 year until dogfood, meaning the 
first most courageous people can try to use it.
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.
Year 3: It will take a third year to achieve reasonable feature parity 
with Thunderbird.

Rome wasn't built in a day. But it was built. And new big cities were 
built after Rome, too.

So, the new components will form the new client. That is the priority.

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.

This approach has the following benefits:

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

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

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.

Don't kill the past. But build the future at the same time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170405/bf6844f4/attachment.html>