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

[Ben Bucksch]

Mark Banner wrote on 4/5/17 10:42 AM:
> On 24/03/2017 17:04, Ben Bucksch wrote:
>>
>> Summary:
>>
>>   * While we implement the new version of Thunderbird, the old
>>     codebase based on Gecko will be maintained until the rewrite is
>>     ready to replace the old one.
>>
> I've been reading your original proposal as "Start a new fresh email 
> client on a new code base from scratch, eventually swap users over to 
> that new code base".

Yes, that is my idea.

> You now seem to be saying "Start a new fresh client, but integrate 
> parts of it back to Thunderbird". Is that correct? If not can you 
> please clarify.

This thought is a concession, because most people here seem to strongly 
believe in a gradual rewrite. I've adapted my proposal based on that 
feedback. I'm saying that a gradual rewrite is not necessarily in 
conflict with my idea, but can work in tandem, both efforts can 
complement each other.

But to be frank: Personally, I'm pretty sure that the gradual rewrite 
will not complete until Gecko becomes unmaintainable in practice, and 
will therefore fail. It's just too much work to marry the old codebase 
with new components gradually, while keeping other old components in 
place. But if other people feel that this is the right way, then fine. 
They can do that. And they can use the components that the effort for 
the new client produces.

I think the truth is probably in the middle somewhere. I think the 
address book will be possible to backport, and will significantly help 
the userbase, until the new client is usable. There will probably be 
other low cost, high gain cases like that. Such backports will be very 
useful. But I don't think it's possible to replace all of old 
Thunderbird step by step, before Gecko sky crashes on us.

> So, define an experiment which is limited in scope and goals, has 
> limited (but enough) resources, but is definitely an experiment.

Great idea. I am doing just that at the moment.

> For that experiment:
>
>   * Define the scope/goals clearly, e.g.
>       o Obtain knowledge of the most viable code base?
>       o Is it likely to be able to support the performance we require?
>         (e.g. multi-threaded/process etc).
>

For example, we've identified the speed of the thread pane (message 
list) as major problem in HTML. That's why I wrote the fastlist test 
<http://benbucksch.github.io/trex/fastlist-test.html>. This was the main 
missing widget in HTML, and it's proven to work, in concept. In fact, it 
can do more than XUL trees could. The rest - hierarchical tree view, 
selection, rich content rows, clean API etc. - is just leg work now.

>       o How are L10n, Add-ons, profiles, etc... supported?
>       o How long might it take to reimplement all of Thunderbird?
>       o What is the minimum MVP we need to be able to answer the
>         scopes/goals?
>

Right. Good questions!

I would like to prove feasibility. It would be nice, if we could define 
some realistic goals, which would - if achieved or at least shown 
possible - give those who have doubts about the project the comfort that 
this is a promising route. I have some goals in mind. But I fear that 
won't help.

It needs to be those who have doubts that define them. But, please be 
realistic. Reasonable milestones. Not all of Rome, in 2 weeks.

> This could be seen as "let's delay the decision", which in part it is, 
> but I think it would give a much better basis on which to make a 
> decision than what seems to be "let's stop work, start something new, 
> currently undefined and hopefully switch to it later".

FWIW, I don't suggest to stop work. My original proposal was maybe 
formulated a little drastic. I am proposing that old Thunderbird 
continues as it has been in the last years. In no way "stop work" on it.

> The 'trick' will be in correctly forming the scope to get enough 
> top-level questions answered, but not going into too much detail and 
> never getting answers.

+1