<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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>
      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.<br>
      <br>
      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).<br>
    </blockquote>
    <br>
    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>
    <br>
    Clearly option 1 is unrealistic: Mozilla are moving away from what
    made Firefox and Thunderbird successful. Thunderbird cannot
    follow[1].<br>
    <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. 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?<br>
    <br>
    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?<br>
    <br>
    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>
    <br>
    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>
    <br>
    <br>
    <br>
    <br>
    Footnotes:-<br>
    1: I think the pressure that Firefox is under is causing Mozilla to
    make some foolish decisions but that's a different subject.<br>
    2: As HTML5 currently stands it would need to be HTML5 with some
    extensions but that's still technically achievable.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Mark Rousell
</pre>
  </body>
</html>