<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      I work on BirdieSync software which synchronizes contacts, events,
      and possibly tasks and mails between Android, iPhone, Windows
      Mobile devices and Thunderbird. I'm concerned about the last news
      about the possible evolutions regarding add-ons. BirdieSync has a
      third-party add-on in Thunderbird which relies on XPCOM and XUL
      through binary components, and uses the needed XPCOM interfaces to
      access to contacts, calendars and mails.<br>
      <br>
      The new step of switching to another technology than XPCOM and XUL
      for add-ons would be problematic at the least. If add-ons would
      need to rely exclusively on WebExtensions API in the future, it
      would mean a huge work having to fully rewrite the add-on, and
      potential lacks in the new restricted API. For instance, the API
      to connect with native applications is only said to be "likely"
      offered by Mozilla and it would be necessary to have a new
      dedicated API in Thunderbird to manage contacts, calendars and
      mails, available to third-party developers.<br>
      <br>
      I hope that alternative solutions will be possible to continue
      offerring access to XPCOM components in Thunderbird, also through
      binary components. I'm aware that the decision of continuing
      offering support of XUL and XPCOM add-ons may not only depend on
      Thunderbird will and may depend on future Mozilla Core evolutions.
      If it couldn't be possible, I only hope that it would be at least
      feasible to achieve with the new API what was possible with XPCOM.<br>
      <br>
      I will take the opportunity of this mail, to thank all the
      Thunderbird team for the great job they do, their hard work and
      involvement !<br>
      <br>
      Chris<br>
      <br>
      Le 8/24/2015 8:35 PM, R Kent James a écrit :<br>
    </div>
    <blockquote cite="mid:55DB63E7.50801@caspia.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      We need to do some sort of announcement in the Thunderbird blog
      about our plans concerning addons. I'd like to have feedback from
      folks to see if there is any debate about what is the correct
      direction for us.<br>
      <br>
      We've at least agreed that we are continuing to support binary
      addons. Concerning signing, we took steps months ago to not move
      forward on requiring addons to be signed, so there are no current
      plans to require signing. There is still some debate about that in
      bug 1168571. We should probably come to a firm decision and
      announce it. Most commenters were opposed to signing, though there
      were some holdouts.<br>
      <br>
      Then there is "<a moz-do-not-send="true"
href="https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/">The

        Future of Developing Firefox Add-ons - The Mozilla Blog</a>"
      that announces the complete disabling of current XUL addons at
      some point in the future. Several Thunderbird community members
      commented on that blog post, strongly opposed to that direction.<br>
      <br>
      Contrast that with <a moz-do-not-send="true"
        href="https://wiki.mozilla.org/Firefox/Go_Faster">Firefox/Go
        Faster</a> where there are plans to expand the use of addons in
      Firefox, adding so-called "system add-ons" and moving Hello to
      one. (This is similar to what we are doing with Lightning, which
      should hopefully make our Lightning integration easier in the
      future).<br>
      <br>
      At this point, I think that the prevailing viewpoint is probably
      the following, and I would like to announce this if possible in a
      blog post:<br>
      <br>
      1)    Thunderbird continues to support binary addons.<br>
      2)    Thunderbird will not require addon signing.<br>
      3)    Thunderbird has no current plans to disable the use of
      traditional XUL/XPCOM addons in Thunderbird.<br>
      <br>
      This policy must be modified by the caveat "as long as core
      Mozilla code can be used to support it".<br>
      <br>
      (I might also note that initial patches are being looked at for
      the integration of the technology formerly know as Skinkglue into
      Thunderbird core, to be called JsAccount, which makes it possible
      to define new account types in Thunderbird using a traditional
      XUL/XPCOM/JavaScript addon. This will almost certainly be in our
      next major release).<br>
      <br>
      Could I have some comments or discussion on these proposed
      positions?<br>
      <br>
      I hope the Thunderbird community appreciates that diverging from
      Mozilla in this manner will probably mean that we will need to
      take over addon review from Thunderbird at some point, possibly
      including forking of AMO for our own use.<br>
      <br>
      :rkent<br>
    </blockquote>
  </body>
</html>