Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Wed Apr 5 08:47:26 UTC 2017
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
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
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...
More information about the tb-planning