<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
    <div id="smartTemplate4-template">Just my comments from the Add-ons
      perspective
    </div>
    <div id="smartTemplate4-quoteHeader">
      <style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
      <blockquote type="cite" style="margin-bottom: -20px !important;
        padding-bottom:20px !important;">
        <div id="newHeaderAG1" style="font-size: x-small; padding:1em;
          background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>Why
          isn't forking an existing email client a possibility?<br>
          <b>From:</b>Eric Moore <a class="moz-txt-link-rfc2396E" href="mailto:emoore@fastmail.fm"><emoore@fastmail.fm></a><br>
          <b>To:</b>Tb-planning <br>
          <b>Sent: </b>Monday, 26/02/2018 09:40:03 09:40 GMT ST +0000
          [Week 9]<br>
        </div>
      </blockquote>
    </div>
    <blockquote type="cite"
      cite="mid:1ab28e87-a1c4-7dca-d2d9-a6d3e284d2d7@fastmail.fm"
      id="mid_1ab28e87_a1c4_7dca_d2d9_a6d3e284d2d7_fastmail_fm" class="
      cite">I don't understand why nobody is discussing the possibility
      of using a open source cross platform email client such as Nylas
      Mail Lives, Mailspring (both forks of Nylus Mail) or MailPile as a
      base for the next generation of Thunderbird. They might not be
      viable choices, but I think they should be seriously evaluated.
      MailPile lagged for a good while but is now at 1.0.0rc2.
      <br>
      <br>
      1. Forking one of them would provide a big head start and avoid
      the whole issue of needing to backport new code to the existing
      Thunderbird. We'd still be free to go our own direction, and
      modify or discard whatever we want.
      <br>
      <br>
      2. Ends the arguments about the fundamental architecture that have
      literally been going on for years and let us focus on more
      specific issues. It would also make it easier to iterate quicker
      because we could initially focus on a few components.
      <br>
      <br>
      3. Makes a clean break with both XPCOM/XUL and the WebExtensions
      API. My impression is that so many Thunderbird add-ons will break
      in the next two major versions that we have little to lose, and
      the current uncertainty/barriers to entry is causing a problem.
      <br>
    </blockquote>
    you may be wrong here. I have kept up with mine, many 1000s lines of
    code, 6 Add-ons. I would be open to port to a new platform if there
    was enough time give and some collaboration offered from the
    Thunderbird core team. The experience with the Firefox code base
    (m-c) is that only a very small subset of functionality was made
    available (I guess mainly because of the web-extension / sandbox
    model restriction)<br>
    <br>
    <blockquote type="cite"
      cite="mid:1ab28e87-a1c4-7dca-d2d9-a6d3e284d2d7@fastmail.fm"
      id="mid_1ab28e87_a1c4_7dca_d2d9_a6d3e284d2d7_fastmail_fm" class="
      cite">
      Letting new authors get up to speed by learning how to write a
      plug-in for an existing GitHub project could be very useful. I'm
      not suggesting that we limit ourselves to what the current plug-in
      API supports, just that it would be a useful base for authors to
      learn the basics from and provide feedback on what they would like
      while the enhanced API is being decided upon.
      <br>
    </blockquote>
    The problem with the API is that it being designed by the core team
    and doesn't necessary reflect what the Add-on authors need. Thee
    problem is that the (Firefox) core development team seems to have a
    very narrow ideae of what Add-ons should be able to do, but then it
    is "only a browser". I see Thunderbird more as a database fat-client
    and I am trying to access its entities (messages, filters, folders,
    search rules, actions) via XPCOM. An API replacing this would have
    to very very complex - I bet it wouldn't figure a high in the list
    of priorities when shipping an alpha version.<br>
    <blockquote type="cite"
      cite="mid:1ab28e87-a1c4-7dca-d2d9-a6d3e284d2d7@fastmail.fm"
      id="mid_1ab28e87_a1c4_7dca_d2d9_a6d3e284d2d7_fastmail_fm" class="
      cite">
      <br>
      Part of what makes Thunderbird "Thunderbird" is the existing user
      interface, support for lots of customization and certain key
      features. But a community of users that are also add-on authors is
      a critical part too. That is disappearing. I suspect that we would
      lose too much momentum/interest if we had to wait over two years
      for a new design from scratch.
      <br>
    </blockquote>
    The learning curve with XUL / XPCOM is steep but it is worth it
    because of its flexibility. The only hard limit is what is coded in
    C++ layer / non scriptable. <br>
    <br>
    <blockquote type="cite"
      cite="mid:1ab28e87-a1c4-7dca-d2d9-a6d3e284d2d7@fastmail.fm"
      id="mid_1ab28e87_a1c4_7dca_d2d9_a6d3e284d2d7_fastmail_fm" class="
      cite">5. If we really are a independent project we should not be
      heavily dependent upon Mozilla specific technologies and what
      direction Mozilla moves next.
      <br>
      <br>
      My impression was that the decision to stick with Mozilla as our
      home was a temporary one done out of expediency, and it would be
      revisited sometime after a next generation Thunderbird was
      available. Regardless of their technical merits some of the
      suggestions for a complete rewrite (Rust, Servo etc.) would bind
      us to Mozilla software forever. Some of the Mozilla technologies
      are also too limiting, making it tough for Thunderbird to remain a
      real desktop email client.
      <br>
    </blockquote>
    <p>If we go this way I think Thunderbird development should should
      include all Add-ons authors who actively support Thunderbird 50 /
      ESR 2018. Writing Add-ons code for Tb and supporting current and
      future users is a big investment of time, so some communication
      between them and Tb planning / community / core developers should
      be warranted.</p>
    <p>Axel</p>
    <p>--<br>
    </p>
    <p>Thunderbird Add-ons Developer <span class="AddonList">(<a
href="https://addons.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/">QuickFolders</a>,
        <a
          href="https://addons.mozilla.org/thunderbird/addon/quickfilters/">quickFilters</a>,
        <a
          href="https://addons.mozilla.org/firefox/addon/quickpasswords/">QuickPasswords</a>,
        <a
          href="https://addons.mozilla.org/thunderbird/addon/zombie-keys/">Zombie
          Keys</a>, <a
          href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/">SmartTemplate4</a>)</span>
      <br>
      Visit my <a href="https://www.youtube.com/c/thunderbirddaily">YouTube
        Channel</a> for email productivity tips </p>
    <p><br>
    </p>
  </body>
</html>