TB Future Dev

R Kent James kent at caspia.com
Thu Oct 22 17:26:41 UTC 2015


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20151022/17c5c31a/attachment.html>


More information about the tb-planning mailing list