Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Wed Apr 5 09:22:02 UTC 2017
Mark Banner wrote on 4/5/17 10:42 AM:
> On 24/03/2017 17:04, Ben Bucksch wrote:
>> * 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
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
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.
More information about the tb-planning