<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks very much for the time you are
      taking to discuss these questions Kent, it is appreciated, but I
      have some follow-up questions if you don't mind (no hurry, just
      when you have time).<br>
      <br>
      On 12/15/2016 11:35 AM, R Kent James <a class="moz-txt-link-rfc2396E" href="mailto:kent@caspia.com"><kent@caspia.com></a>
      wrote:<br>
    </div>
    <blockquote
      cite="mid:f1549c60-8bed-7893-0818-68a12b0f1239@caspia.com"
      type="cite">
      <pre wrap="">It is really hard for us to predict what mozilla-central is going to do with XUL and the code that supports it. I should probably have listed a fourth option, which is actually I think the path that we are on implicitly, which is 4) continue Thunderbird indefinitely as a XUL/XPCOM app, forking Gecko at the point where that is no longer viable under mozilla-central.</pre>
    </blockquote>
    <br>
    I still don't clearly understand the implications of this.<br>
    <br>
    If the choice is a forked Gecko, how does that impact Thunderbird,
    bottom line?<br>
    <br>
    Is it security? If so, is the most important issue security with
    respect to the rendering of HTML emails?<br>
    <br>
    If so, I would think a way could be found to simply limit the
    capabilities of said rendering, and strictly forbid anything that
    could be a real security risk.<br>
    <br>
    First thing I'd do is eliminate the ability to 'open a web page in a
    Thunderbird tab' - just have TB open the page in the OS' default web
    browser (or a defined web browser of choice).<br>
    <br>
    Would that really be that difficult or impossible of a task?<br>
    <br>
    <blockquote
      cite="mid:f1549c60-8bed-7893-0818-68a12b0f1239@caspia.com"
      type="cite">
      <pre wrap="">If we do nothing, that is the future. And that is probably the future that many people want. A year ago I predicted that about now we would be no longer be able to maintain day-to-day compatibility with mozilla-central, forcing us into resyncing with Gecko periodically, and that at the point of the next major release (59?) we would have to fork Gecko. In hindsight I was overly pessimistic about the timing, but I still think that is the path we are on. That is a path to a slowly dying Thunderbird.</pre>
    </blockquote>
    <br>
    Can you elaborate on this? Why would this necessarily be the case?
    If TB really is nearly feature complete, as many of us believe, why
    would it be a bad thing to just focus on bug fixing, and rewriting
    aspects that need it (Address Book, Composer, etc)?<br>
    <br>
    <blockquote
      cite="mid:f1549c60-8bed-7893-0818-68a12b0f1239@caspia.com"
      type="cite">
      <pre wrap="">If that is what our donors want, then we'll have to think really hard about whether that is how we should spend their money, but for me as a volunteer interested in Thunderbird as a learning opportunity, I have no interest in that.</pre>
    </blockquote>
    <br>
    Well, I think if TB simply forked Gecko at the point where it became
    absolutely necessary, that would eliminate the work needed to
    'maintain' Gecko, freeing up resources to focus on rewriting core
    code that is sorely needed (see above).<br>
    <br>
    I just don't see the downside to this road, but maybe its because
    I'm not a programmer and don't have a clue about the different
    moving parts.<br>
    <br>
    <blockquote
      cite="mid:f1549c60-8bed-7893-0818-68a12b0f1239@caspia.com"
      type="cite">
      <pre wrap="">As to the future of Thunderbird addons, unlike plans for future Firefox addons, a first-class Thunderbird addon needs to be able to have the full capability of the core program. In the option 2) that is likely to be some sort of code injection, like a restartless addon. Whether we can solve the security issues associated with that is another open question.</pre>
    </blockquote>
    <br>
    But this would also require a completed full rewrite of all of the
    core code, right? Something I thought wasn't a viable option right
    now?<br>
  </body>
</html>