<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-template">
<p>Dear Magnus,</p>
<p>
<blockquote type="cite">or add-on authors going forwards, there
is of course also an option C (depending on what the add-on
does): work with us to integrate the functionality into core.
</blockquote>
I actually thought about this myself - if it means not losing
the "privileged access" to the JavaScript / XPCOM layer it may
mean a lot less work than constantly adapting an Add-on. There
is only one problem - over the 10 years I am working4 on this
project I have managed to turn it into a paid / self-employed
thing, and with the amount of work ahead and to maintain the
functionality, the only way to recoup would be to turn into a
Thunderbird employee. <br>
</p>
<p>I am not sure if that's the correct way forward for me - would
it possible to imagine a specialized / subcontractor position
for an Add-ons developer so they can focus on just that specific
work / functionality, rather than being deployed into stuff we
may not be interested in? <br>
</p>
<p>The other argument against core is that only a small group of
users may be interested in the functionality of these legacy
extensions, and by rights <i><b>they </b></i>should be the
ones funding that. A "Thunderbird advanced" / freemium model
might be a way out here. Just brain storming...<br>
</p>
<p>Axel</p>
<style type="text/css">.myName {
text-shadow: 1px 1px 2px #DDD;
transition:font-size 0.5s;
}
.myName:hover, .myName a:hover
{ font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
.moz-signature {opacity: 1.0 !important;}
.myName a { cursor: pointer !important; transition:font-size 0.5s;}
.myLogo {
transition: all .4s ease-out;
}
.myLogo:hover {
transform: scale(3) translate(-30px,-5px);
}
#mySignature, :not(blockquote) #mySignature {
background: rgb(230,240,163);
background-image: linear-gradient(to bottom, rgba(230,240,163,1) 0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1) 51%,rgba(219,240,67,1) 100%);
color: #444;
box-shadow: 4px 4px 9px -2px rgba(0,0,0,0.65);
border-radius: 0.7em; padding: 0.8em 1.2em;
border: 1px dashed #8080A0;
font-size: 11pt !important;
font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;
width: 65%;
}
.AddonList a {
color: #666666;
font-size: 10pt !important;
}
</style>
<div id="mySignature"> <b class="myName"><a
href="mailto:axel.grude@gmail.com">Axel Grude</a></b> <br>
Music Production and Composition <br>
Thunderbird Add-ons Developer <span class="AddonList">(<a
href="https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/">QuickFolders</a>,
<a
href="https://addons.thunderbird.net/thunderbird/addon/quickfilters/">quickFilters</a>,
<a
href="https://addons.mozilla.org/firefox/addon/quickpasswords/">QuickPasswords</a>,
<a
href="https://addons.thunderbird.net/thunderbird/addon/zombie-keys/">Zombie
Keys</a>, <a
href="https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/">SmartTemplate⁴</a>)</span>
<br>
Visit my <a href="https://www.youtube.com/c/thunderbirddaily">YouTube
Channel</a> for email productivity tips <img
style="margin-top: 1em; float: right; box-shadow: 1px 1px 2px
rgba(20, 20, 20, 0.4);" moz-do-not-send="false" class="myLogo"
src="cid:part8.74DBD747.9558CFF9@gmail.com" alt="Get
Thunderbird!" width="94" height="15">
</div>
</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>Re:
Intent to de-support: traditional add-ons<br>
<b>From:</b>Magnus Melin <a class="moz-txt-link-rfc2396E" href="mailto:mkmelin+mozilla@iki.fi"><mkmelin+mozilla@iki.fi></a><br>
<b>To:</b><a class="moz-txt-link-rfc2396E" href="mailto:tb-planning@mozilla.org"><tb-planning@mozilla.org></a> <br>
<b>Sent: </b>Tuesday, 10/15/2019, 11:19 11:19 IST +0100 [Week
42]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:96f3cb1a-8052-2f76-3211-e54998c85d28@iki.fi">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>A few clarifications:</p>
<p>The changes are for the general public only going to come into
effect in the next ESR release, Thunderbird 78 in mid 2020. For
developers, in beta and nightly support will start to disappear
from core once we're ready do so, probably during 2019. Some
notable things that will be removed are the custom overlay
loader (Overlays.jsm), and support for add-ons requiring
restart.<br>
</p>
<p>For add-on authors going forwards, there is of course also an
option C (depending on what the add-on does): work with us to
integrate the functionality into core. If the add-on is under
the bug-fix category this is certainly the way to go as no API
for a bug-fix would be in sight. In general we're happy to
include functionality provided it's of general usefulness. <br>
</p>
<p>MailExtension Experiments is one way to go (and that's not
deprecated), but should not be seen as a long term solution. It
may be a short term solution though. It means you need to follow
changes closely and things will often break. Sometimes in ways
that could be hard to solve. They simply need to be understood
to be seen as experiments, with no warranties.</p>
<p> -Magnus<br>
</p>
<div class="moz-cite-prefix">On 01-10-2019 16:02, Magnus Melin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2bb9a19f-904c-e50c-33f1-eecabcc8b860@iki.fi">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Since version 57, Firefox only supports add-ons through the
WebExtensions APIs. At the time, Thunderbird decided to
continue supporting traditional add-ons, since we hadn't yet
been able to develop replacing APIs for add-on developers to
use. <br>
</p>
<p>Since then, Thunderbird has been developing WebExtensions
APIs (aka MailExtensions), and the number of APIs available is
continuously growing: <a class="moz-txt-link-freetext"
href="https://thunderbird-webextensions.readthedocs.io/"
moz-do-not-send="true">https://thunderbird-webextensions.readthedocs.io/</a><br>
</p>
<p>Because the toolkit support for traditional add-ons has been
largely removed, this has meant a lot of work for Thunderbird
to keep things going for add-ons. For the server side it has
also meant a lot of extra work (addons.thunderbird.net is a
fork of addons.mozilla.org). Add-on developers haven't had an
easy ride either: The number of changes to make an add-on
compatible has been significant. <br>
</p>
<p>Going forwards we want to change this. Support for
traditional add-ons is going to be dropped as soon as we're
ready to do so internally. There are a few pieces of code that
we need to convert over internally: <br>
</p>
<ul>
<li>Lightning: to be integrated into the code base<br>
</li>
<li>Mozmill (used in our test infra): we're converting over to
using mochitests instead</li>
</ul>
It's not yet clear exactly when we're ready to rip out the
support for traditional add-ons from the code base, but it
should be whitin the Thunderbird 72 time frame - so by end of
2019. The next major version of Thunderbird, version 78, will be
out around June 2020. Up until then, code wise many things are
going to change. For instance, what is left of XUL will be
gradually going away, and documents will shifted to being XHTML
with a less and less XUL flavor. <br>
<p>Dropping support for non-MailExtension add-ons is also needed
for addons.thunderbird.net. Supporting old-style add-ons would
require a significant investment in the back-end there, since
the Django version of the back-end would reach EOL and have to
go through a painful and expensive upgrade.</p>
<p>As an author of a traditional add-on, what should you do?
There are two routes: A) convert your add-on to a
MailExtension. If the API you need doesn't exist yet, <a
moz-do-not-send="true"
href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=Add-ons:%20Extensions%20API">tell
us about it</a>. B) convert your add-on to a <a
moz-do-not-send="true"
href="https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html">Web
Extension Experiment</a>. Most add-ons should be able to be
converted to an experiment with a reasonable effort. The
recommended path is forward is to convert it to an a
MailExtension though. That will make sure the add-on works
without significant changes over many years. If you go with
option B, you'll have to maintain a lot of more code yourself
and breakages can and will be bad unless you keep up really
close. MailExtension Experiments should be seen as such,
experiments with the goal of getting the API they need into
Thunderbird core. Please work with us on getting the needed
pieces in as a supported API. Initially we'll be allowing
experiments to be exposed to the general public, but over time
(years) Thunderbird will gravitate towards not having the
experiments available to the general public, the same way it
works for Firefox.<br>
</p>
<p> -Magnus<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
</body>
</html>