TB Future Dev

[jsabash]

https://upload.wikimedia.org/wikipedia/commons/thumb/4/43/Phoenix-Fabelwesen.jpg/440px-Phoenix-Fabelwesen.jpg

"Investigated Github atom/electron as a development environment for a post-Gecko Thunderbird.
It would be really good to have some partners in long-term work for Thunderbird.
Gecko Thunderbird is dying, is there any debate about that?"

I'm sorry Kent, I just can't make it to the meetings.
They are just at my transit time after work.

I would like a little clarification on this statement.
Gecko to me is the basic rendering engine of a browser or Mail App

Maybe you were referring to the Dev-environement, and not the basic renderer.
Achieving "Browser" class rendering of email is very important to some folks.

So if we deviate from Mozilla on the Development infra
My hope is we never become a 2nd class HTML/CSS message renderer.

Anyhow, Grand plans and hopes and schemes have been dashed before
But there has always been a resurgence ala the Phoenix
Also a legendary bird.

--

JoeS ... "Get a Gecko"
TB Release Vers TB Trunk SeaMonkey

[neandr]

Hi Kent,

let me comment your point with the last
/thunderbird-status-meeting-minute-taking
> * Investigated Github atom/electron as a development environment for a

> post-Gecko Thunderbird. It would be really good to have some partners
> in long-term work for Thunderbird. Gecko Thunderbird is dying, is
> there any debate about that?

Also it's more than a valid idea to start a discussion about a good dev
platform for a future TB, is there a discussion about the impact of the
massive code base change (Gecko, XUL, more ..)? Think it will not be
possible to replace parts only of that a very complex, huge software
system TB. Isn't there the need to eventually re-model it?

FMPOV the same will be true for Firefox also. So is there a concept to
share it within the "Mozilla House"? Wouldn't this predetermine the
future software *and* (maybe also the) development base for TB also?

As an add-on developer for FX/TB I was very much struggling with the dev
documentation*s*. So "re-starting" Thunderbird would be a great change
to get a better base for modelling/development/documentation.

With your question:

> is there any debate about that?

Guenter

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Tanstaafl]

What did I miss? I don't see any post anywhere regarding this?

[Tanstaafl]

Never mind - I missed reading the recent meeting notes...

This is going to be interesting. I'm currently working very hard at
becoming independently wealthy so I can 'adopt' Thunderbird... ;)

[R Kent James]

On 10/20/2015 6:14 PM, jsabash wrote:

"Investigated Github atom/electron as a development environment for a post-Gecko Thunderbird.
It would be really good to have some partners in long-term work for Thunderbird.
Gecko Thunderbird is dying, is there any debate about that?"

I would like a little clarification on this statement.
Gecko to me is the basic rendering engine of a browser or Mail App

At the meetings, I tend to raise difficult issues that are not easily expressed as a two-sentence summary. Let me clarify.

Gecko development is currently tightly focused on improving Firefox as a product. Mozilla as an organization has defined its mission as promoting "the Web" which seems to mean the HTML/CSS/JavaScript development platform. Neither of these goals is compatible with the current Thunderbird development environment, which is essentially recompiling Firefox to function as an email client. We also need to realize that Firefox is under tremendous pressure right now, so they have precious little bandwidth to focus on anything other than their own long-term relevance. We can neither demand nor expect that Firefox revenue will be used to subsidize Thunderbird development, either directly or even indirectly as now.

A good example is the discussion we recently had about how addon changes will affect Thunderbird. Blake Winton (who is a key player now in the Web Extensions world) said "It isn't being designed to work with Thunderbird, and I'm not even sure they would accept patches that got it working with Thunderbird". We can expect more and more changes like this in the future, with things like XUL deprecation, Electrolysis, and Servo in the Firefox world leading to an increasingly difficult operating environment for Thunderbird in the Gecko binary world.

So it seems to me that long-term we have these three long-term choices:

1)    Assume that either Firefox is bluffing about their upcoming changes, or imagine that somehow we can adapt to them, even when the Firefox team itself has no long-term commitment to continue to support Thunderbird as a application target for a Gecko binary.

2)    Fork mozilla-central at some future point when Thunderbird support becomes untenable, and try to maintain it ourselves.

3)    Rework Thunderbird to work on an alternate development platform that has a long-term future.

The current "plan" is path 1) which IMHO is really path 2). I do not believe that is a viable long-term plan. I laid out a plan in my post "Thunderbird as a Web App" that essentially set down a three-year timetable for a transition to an alternate platform that used Web technologies.

At the meeting, my point was that I do not sense other people having the same sense of urgency and commitment to a long-term transition that I seem to feel. I outlined some of my investigations into the Atom/Electron development environment, which is a Github (the company) project to make a development environment for desktop applications that provides a platform for making Mac/Linux/Windows apps that use nodejs as the backend. This is exactly where we seem to be headed, so I think that we should experiment with that platform. I switched this weekend to Atom as my editor to get some feel for this (and discovered that it crashes several times per day).

The quote in the notes "Gecko Thunderbird is dying, is there any debate about that?" is asking if anyone really believes that plan 1) or plan 2) is the right long-term plan. If not, then we really need to get more people to focus on the transition issues.

:rkent

[Walter L Schwartz]

I had to look here.

<https://public.etherpad-mozilla.org/p/thunderbird-status-meeting-minute-taking>

[Mark Rousell]

On 21/10/2015 18:39, R Kent James wrote:

So it seems to me that long-term we have these three long-term choices:

1)    Assume that either Firefox is bluffing about their upcoming changes, or imagine that somehow we can adapt to them, even when the Firefox team itself has no long-term commitment to continue to support Thunderbird as a application target for a Gecko binary.

2)    Fork mozilla-central at some future point when Thunderbird support becomes untenable, and try to maintain it ourselves.

3)    Rework Thunderbird to work on an alternate development platform that has a long-term future.

The current "plan" is path 1) which IMHO is really path 2). I do not believe that is a viable long-term plan. I laid out a plan in my post "Thunderbird as a Web App" that essentially set down a three-year timetable for a transition to an alternate platform that used Web technologies.

At the meeting, my point was that I do not sense other people having the same sense of urgency and commitment to a long-term transition that I seem to feel. I outlined some of my investigations into the Atom/Electron development environment, which is a Github (the company) project to make a development environment for desktop applications that provides a platform for making Mac/Linux/Windows apps that use nodejs as the backend. This is exactly where we seem to be headed, so I think that we should experiment with that platform. I switched this weekend to Atom as my editor to get some feel for this (and discovered that it crashes several times per day).

Looking at the above three long-term choices, it seems to me that option 2 offers the best chance for long-term real-world sustainability considering where we are starting with Thunderbird.

Clearly option 1 is unrealistic: Mozilla are moving away from what made Firefox and Thunderbird successful. Thunderbird cannot follow[1].

Option 3 on the other hand is a 'start over' solution: It risks what seems to happen perhaps too often in some projects (but not this one so far), where things get crufty and it seems tempting to start over with the latest technologies. However, the latest fads and technologies come and go. Stability is important and such technologies do not tend to promote stability. Is there anything special about the start over approach (other than that it is the latest cool thing) to recommend it?

This leaves option 2, which is essentially (if I understand correctly) to fork Gecko and the Mozilla platform as it currently stands (before it is changed beyond what we can follow). And why not? Mozilla may be moving away from Gecko/XUL for Firefox but it works for Thunderbird. It essentially does what we need, doesn't it?

I asked the semi-rhetorical question above "And why not?" in relation to going with option 2. I can see a couple of possible reasons that might make option 2 difficult:
(1) Development resources to continue maintaining the forked Gecko and Mozilla platform. Does (or will) the Thunderbird project have adequate resources to do this? Of course, any brand new platform will also need considerable development resources too (and will become crufty in time), so worrying about maintaining Gecko/Mozilla might be a straw man.
(2) Does the current Gecko/Mozilla platform impose any massive limitations on Thunderbird that only an entirely new platform could work around?

Whatever happens, let's not go down what seems to be the Mozilla route of throwing away the hugely flexible extensions capability that XUL/Gecko currently provides. This capability, above all else, is what made Thunderbird and Firefox successful. We should never underestimate the value of ecosystem.

(For the avoidance of doubt, I should add that I don't see XUL/CSS/JS as necessarily the only way to provide ultimate UI/extension flexibility; a UI written in HTML5[2]/CSS/JS could provide similar flexibility, but equally I see no good reasons as things stand to move away from XUL/CSS/JS if Gecko can be forked).





Footnotes:-
1: I think the pressure that Firefox is under is causing Mozilla to make some foolish decisions but that's a different subject.
2: As HTML5 currently stands it would need to be HTML5 with some extensions but that's still technically achievable.

-- 
Mark Rousell

[R Kent James]

On 10/22/2015 6:56 AM, Mark Rousell wrote:

On 21/10/2015 18:39, R Kent James wrote:

So it seems to me that long-term we have these three long-term choices:

1)    Assume that either Firefox is bluffing about their upcoming changes, or imagine that somehow we can adapt to them, even when the Firefox team itself has no long-term commitment to continue to support Thunderbird as a application target for a Gecko binary.

2)    Fork mozilla-central at some future point when Thunderbird support becomes untenable, and try to maintain it ourselves.

3)    Rework Thunderbird to work on an alternate development platform that has a long-term future.

Looking at the above three long-term choices, it seems to me that option 2 offers the best chance for long-term real-world sustainability considering where we are starting with Thunderbird.

If you look at my previous post, I see this as happening during year 3 of a transition plan. I think it is inevitable at some point, the only real question is whether esr45, esr52 or later is the last Gecko target for Thunderbird. I just don't think that is sustainable for more than a year or two.

Option 3 on the other hand is a 'start over' solution: It risks what seems to happen perhaps too often in some projects (but not this one so far), where things get crufty and it seems tempting to start over with the latest technologies. However, the latest fads and technologies come and go.

HTML and JavaScript are hardly "the lastest fad".

I asked the semi-rhetorical question above "And why not?" in relation to going with option 2. I can see a couple of possible reasons that might make option 2 difficult:
(1) Development resources to continue maintaining the forked Gecko and Mozilla platform. Does (or will) the Thunderbird project have adequate resources to do this? Of course, any brand new platform will also need considerable development resources too (and will become crufty in time), so worrying about maintaining Gecko/Mozilla might be a straw man.
(2) Does the current Gecko/Mozilla platform impose any massive limitations on Thunderbird that only an entirely new platform could work around?

You can't predict the future, but you can study the past. We're talking long-term here, right? Would we be happy if we were running today on Gecko 3 or 4? Would we have been able to maintain the platform with changes in compilers and operating systems since then? It's not just Gecko, it's tooling such as the build system and all of the other pieces of the Mozilla infrastructure that support development. Would we be updating SSL to overcome various threats? Or be happy with JavaScript circa 2010?

I think not.

Whatever happens, let's not go down what seems to be the Mozilla route of throwing away the hugely flexible extensions capability that XUL/Gecko currently provides. This capability, above all else, is what made Thunderbird and Firefox successful. We should never underestimate the value of ecosystem.

(For the avoidance of doubt, I should add that I don't see XUL/CSS/JS as necessarily the only way to provide ultimate UI/extension flexibility; a UI written in HTML5[2]/CSS/JS could provide similar flexibility, but equally I see no good reasons as things stand to move away from XUL/CSS/JS if Gecko can be forked).

The XUL-overlay parts of most of my addons do nothing more than inject a JavaScript file into the context of a particular XUL page. The issue is not really XUL, but whether Thunderbird will maintain the ability of addons to provide full system-level access to injected code.

I would like to say yes, and I sincerely hope that "yes" is the answer, but at the same time I need to challenge the Thunderbird community on this. One of the arguments against this is that it makes it enormously difficult to review addon code for malicious or dangerous activity, and it makes it hard to maintain compatibility.

On reviews, the addon editors have tried for years to survive on volunteers. There have been precious few volunteers from the Thunderbird community. I listen to what Axel has to say partly because he has contributed enormously in this area.

On compatibility, an addon editor (TheOne) updated at great effort the addon compatibility checker for Thunderbird 31, for Thunderbird 38 nobody stepped forward and we just abandoned the effort.

Powerful addons require commitment to maintain, and so far Thunderbird has mostly hoped that the Firefox people will do that work. And the Firefox people are saying that even for Firefox, it is too much work.

So there are significant costs to maintaining powerful addons, and we need a plan to bear those costs.

:rkent