<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>> 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</p>
<p>Can contact information for add-on developers be pulled from
<a class="moz-txt-link-freetext" href="https://addons.mozilla.org/en-US/thunderbird/">https://addons.mozilla.org/en-US/thunderbird/</a> ? If so, could they
be asked to provide input via
<a class="moz-txt-link-freetext" href="https://discourse.mozilla.org/c/thunderbird/addons">https://discourse.mozilla.org/c/thunderbird/addons</a> ?<br>
</p>
> Which brings me to the other question - who is going to review
mail Add-ons?<br>
<br>
Drupal provides git hosting for modules and themes on drupal.org.
That allows them to completely block any modules that drop the ball.
They also have a security report workflow for people to report
security issues to people other than the module developer. Could
Thunderbird do something similar? Perhaps an instance of GitLab? I'm
pretty sure we could form a solid security review process using it.
(I run a small instance at work, so I know it works well. And I've
been using GitLab.com for my personal projects. That's why I suggest
it, of course, if there's a similar tool that works better, we'd
want to use that.)<br>
<br>
- David<br>
<br>
<div class="moz-cite-prefix">On 04/21/2018 09:50 AM, Axel Grude
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a81ccd58-bb3f-9786-585b-d006ebcbd9cc@gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<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" moz-do-not-send="true">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/"
moz-do-not-send="true">QuickFolders</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/quickfilters/"
moz-do-not-send="true">quickFilters</a>, <a
href="https://addons.mozilla.org/firefox/addon/quickpasswords/"
moz-do-not-send="true">QuickPasswords</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/zombie-keys/"
moz-do-not-send="true">Zombie Keys</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/"
moz-do-not-send="true">SmartTemplate4</a>)</span> <br>
Visit my <a href="https://www.youtube.com/c/thunderbirddaily"
moz-do-not-send="true">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.98E50249.93238E78@reagannetworks.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"
moz-do-not-send="true"><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"
moz-do-not-send="true">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"
moz-do-not-send="true"><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"
moz-do-not-send="true">tb-planning@mozilla.org</a> <br>
<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>
<br>
</blockquote>
_______________________________________________ <br>
tb-planning mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a>
<br>
<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>
<br>
</blockquote>
<br>
_______________________________________________ <br>
tb-planning mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a>
<br>
<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>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>
<br>
</body>
</html>