<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">
<p>Dear David,</p>
<p>I would strongly suggest to wait until Thunderbird Council has
a plan unless you have no problem re-writing. If you have
invested a lot of time & resources already then "the only
way out is through", which means go along with any changes by
Thunderbird development team and hope they do not take away too
much functionality. I certainly hope it's never going to be an
all-or-nothing situation like with Fx Quantum. <br>
</p>
<p>Further question: How do we mobilize all current (active)
Add-ons developers to help with the transition? Will they be
asked? I don't think there is a good forum / mailing list that
interfaces between Thunderbird Code and Add-ons development I
think this should be established before doing a lot of extreme
breaking changes. There must be a way to negotiate between the
two - certainly I do not like if privileged access to the script
layer is restricted just because we are "Only" writing Add-ons.
<br>
</p>
<p>If you want deep functionality from your software, you need to
give it deep privilege. Which brings me to the other question -
who is going to review mail Add-ons? Again I offer some time for
this as it will become necessary if Mozilla.Fx doesn't want to
support it anymore.<br>
</p>
<p>Axel<br>
</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.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 <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.15857B99.3F04A2B5@gmail.com" alt="Get
Thunderbird!" height="15" width="94">
</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:
Supporting future addon development<br>
<b>From:</b>David Reagan <a class="moz-txt-link-rfc2396E" href="mailto:david@reagannetworks.com"><david@reagannetworks.com></a><br>
<b>To:</b>Tb-planning <br>
<b>Sent: </b>Saturday, 21/04/2018 17:07:01 17:07 GMT ST +0100
[Week 16]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:bf8e853c-7e24-3404-029b-9d697f266acf@reagannetworks.com"
id="mid_bf8e853c_7e24_3404_029b_9d697f266acf_reagannetworks_com"
class=" cite">Hey all,
<br>
<br>
With all the uncertainty surrounding add-ons, what should someone
who has never developed one, but wants to do so, do?
<br>
<br>
Learn the old way that is going to get retired? Wait? Learn
WebExtensions for Firefox in hope that will apply to Thunderbird
down the road?
<br>
<br>
Could someone update
<a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57">https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57</a> with a
recommended way to get started during this transition period?
<br>
<br>
Thanks!
<br>
<br>
- David Reagan
<br>
<br>
<br>
On 04/21/2018 08:27 AM, Philipp Kewisch wrote:
<br>
<blockquote type="cite" id="Cite_8025829" class=" cite">Hi folks
<br>
<br>
I agree a lot with Magnus here, we are looking into alternatives
going forward. It is true that starting with Thunderbird 61,
legacy xul add-ons are no longer supported by the Mozilla
Platform. We could certainly cling to this tech and fork m-c,
but this also means we would spend a great amount of effort in
recreating the old technology just to stand still.
<br>
<br>
We are experimenting with various approaches for extension
authors to continue to maintain their add-ons with only minimal
migration effort.
<br>
<br>
One such experiment, which I feel is very promising, is to
introduce WebExtensions, but with a twist: there is an escape
hatch to legacy technology. This means you can continue to run
legacy add-ons, and all you need to do is use a specific
manifest.json property, and drop the install.rdf.
<br>
<br>
On the plus side, you don’t need to go about a rewrite of your
add-on. We don’t have all the APIs you need anyway. On the other
hand, you are still responsible for adapting to Gecko changes
which can be high pace, as it has already been.
<br>
<br>
If we go forward with this approach, it would not make sense to
keep this backdoor open forever. We would have yet another
technology to maintain, and add-on devs will have an increasing
amount of gecko changes to make. In the end, both sides will
fold under maintenance burden.
<br>
<br>
To counteract, we would additionally enable “WebExtension
Experiments” on release. This is a way for an add-on to provide
a WebExtension API, which is itself is implemented using
internal gecko APIs. You could for example for example create an
API that provides a listener that fires on new mail arriving.
The api uses the internal observers you know and love on the
inside, but could provide a simple
browser.mailRequest.onEmailArriving.addListener() api on the
outside.
<br>
<br>
A such API from my example has a high chance of being accepted
in Thunderbird (after all, what would a mail api be without
it?). This shifts the burden to Thunderbird core developers, and
if we completely change the new mail notification mechanism, or
a gecko api goes away, it would not affect you as a user of the
WebExtension API.
<br>
<br>
This way, we can involve add-on developers in creating general
use apis, so that you don’t have to fear all the functionality
being taken away from you. Once we have a good amount of general
apis, we can consider closing the backdoor.
<br>
<br>
For those considering to rewrite as a bootstrapped add-on,
please instead consider going the WebExtension API route. If
Gecko gets rid of bootstrapped add-ons you’d have twice the
work.
<br>
<br>
This isn’t a final plan, we’ve just started experimenting.
Therefore I can’t give you specific instructions on what you
need to change in your add-on just yet. If you would like to
help out in creating new APIs for Thunderbird and testing out
this functionality please get in touch.
<br>
<br>
Philipp
<br>
<br>
<blockquote type="cite" id="Cite_6456401" class=" cite">On 21.
Apr 2018, at 4:05 PM, Magnus Melin
<a class="moz-txt-link-rfc2396E" href="mailto:mkmelin+mozilla@iki.fi"><mkmelin+mozilla@iki.fi></a> wrote:
<br>
<br>
We're still working to see if it's viable to allow the
traditional overlay mechanism for 61 and beyond, Patrick B has
a patch to simulate it using JavaScript.
<br>
But bootstrapped add-ons, which will at least still be
supported, can change/access anything overlay add-ons can, so
there is no loss in functionality. Only that it's a bit more
elaborate to do.
<br>
<br>
-Magnus
<br>
<br>
<blockquote type="cite" id="Cite_5357013" class=" cite">On
21-04-2018 16:53, Axel Grude wrote:
<br>
Both at least XPCOM access and the overlay mechanisms are
vital for writing functioning "deep" add-ons (whether you
label that legacy or some other term doesn't really matter
and does not detract from the fact that it is currently not
replaced with a viable alternative that gives full access to
everything.
<br>
</blockquote>
_______________________________________________
<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>
</blockquote>
_______________________________________________
<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>
</blockquote>
<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>
</blockquote>
<br>
<br>
</body>
</html>