<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 10/22/2015 6:56 AM, Mark Rousell wrote:<br>
<blockquote cite="mid:5628EB0C.6060007@signal100.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
On 21/10/2015 18:39, R Kent James wrote:<br>
<blockquote cite="mid:5627CDD6.8020509@caspia.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
So it seems to me that long-term we have these three long-term
choices:<br>
<br>
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.<br>
<br>
2) Fork mozilla-central at some future point when Thunderbird
support becomes untenable, and try to maintain it ourselves.<br>
<br>
3) Rework Thunderbird to work on an alternate development
platform that has a long-term future.<br>
<br>
</blockquote>
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.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:5628EB0C.6060007@signal100.com" type="cite"> <br>
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.</blockquote>
<br>
HTML and JavaScript are hardly "the lastest fad".<br>
<br>
<blockquote cite="mid:5628EB0C.6060007@signal100.com" type="cite"> 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:<br>
(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.<br>
(2) Does the current Gecko/Mozilla platform impose any massive
limitations on Thunderbird that only an entirely new platform
could work around?<br>
</blockquote>
<br>
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?<br>
<br>
I think not.<br>
<br>
<blockquote cite="mid:5628EB0C.6060007@signal100.com" type="cite">
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.<br>
<br>
(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).<br>
<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
So there are significant costs to maintaining powerful addons, and
we need a plan to bear those costs.<br>
<br>
:rkent<br>
<br>
</body>
</html>