TB Future Dev
mark.rousell at signal100.com
Thu Oct 22 13:56:28 UTC 2015
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
> 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.
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
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/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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning