<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Let me just state that I do <b>not</b>
      share Eyal's position on this matter.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">
      <div class="moz-cite-prefix">I agree with sancus for example that
        removing support for legacy XUL extensions in ATN was a fair
        choice. The alternative would have been to fork AMO/ATN, and
        it's a huge and complicated codebase, and that would not have
        been reasonable. The decision made was sound.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
    </div>
    <div class="moz-cite-prefix">But I would like TB to find ways to
      make life less painful for extension developers. There are many
      low hanging fruits for immediate relief that are not difficult to
      implement. There are also many different ways to help.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">My approach is to look at the
      cumulative work: If 300 extensions need to do 1h of work each
      (300h total), or alternatively TB project needs to do 10h of work,
      I think we should let TB help out. It would be a net positive.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I also think that TB project should be
      more active in finding new volunteer owners for abandonned addons
      that are in active use. In the interest of our end users to have a
      smooth upgrade.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Little decisions like that make a huge
      difference in the result.<br>
    </div>
    <p>Ben<br>
    </p>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Am 24.09.20 um 10:01 schrieb Eyal
      Rozenberg:<br>
    </div>
    <blockquote type="cite"
      cite="mid:74d66115-20dd-05ec-4d33-40345aa174c3@technion.ac.il">
      <br>
      <br>
      On 24/09/2020 2:51, Andrei Hajdukewycz wrote:
      <br>
      <blockquote type="cite">I'm sure Wayne meant client/core
        developers. </blockquote>
      <br>
      Well, that's not what Wayne said. And if that's what he meant,
      this illustrates how us extension developers are semi-consciously
      thought of as inconsequential, not peers who must be part of
      decision making; and that IMHO  is the result of a failure of
      leadership.
      <br>
      <br>
      <blockquote type="cite">I don't know why the same
        <br>
        people keep trying to re-litigate this,
        <br>
      </blockquote>
      > transition to web extension APIs
      <br>
      > was guaranteed to happen in Thunderbird the moment Mozilla
      decided
      <br>
      > that's the way Firefox was going. We delayed it as long as
      reasonably
      <br>
      > possible. More than reasonably, IMO.
      <br>
      <br>
      Until a couple of months ago, I was sure you were right: It's
      something that just happens to us, out of our control, a done
      deal, Firefox forced our hand etc.
      <br>
      <br>
      But that's simply false: It is an arbitrary choice that we are
      making - to strip extensions of their privileges and not to offer
      a decent loader. The alternative is so easy, that most of it can
      be accomplished by a few thousand lines of JS thanks to John
      Bieling ("WindowListener").
      <br>
      <br>
      Also, there is no such thing as "transition". It's a cancellation
      of extensibility. That is terrible and unacceptable. I hope we can
      overturn this after the elections.
      <br>
      <br>
      <blockquote type="cite">Unless you want to argue for rebuilding
        Thunderbird on some other engine
        <br>
        it was never going to be possible to make them work forever.
        <br>
      </blockquote>
      <br>
      Again, this is simply untrue. (Almost) all we are missing is a
      facility for loading extensions within Thunderbird. Our regular,
      non WE extensions work just fine in Thunderbird 78 once we've
      loaded them. With a little bit of effort we would probably just be
      able to load chrome.manifest-based extensions (perhaps with some
      tweaks).
      <br>
      <br>
      We are wasting everybody's time and resources with replicating
      APIs and making people rewrite their extension code when this is
      absolutely not necessary.
      <br>
      <br>
      Eyal
      <br>
      <br>
      PS - Some new APIs may not be a bad idea, but they should not be
      about what extensions are and aren't allowed to run.
      <br>
      _______________________________________________
      <br>
      tb-planning mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
      <br>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>