<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/21/18 7:10 PM, David Reagan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b1b79797-5cd0-643f-b045-58c5eefb6ec4@reagannetworks.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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/"
moz-do-not-send="true">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"
moz-do-not-send="true">https://discourse.mozilla.org/c/thunderbird/addons</a>
?<br>
</p>
</blockquote>
<p>We have means to contact all developers (who have opted in). Once
we are at the stage where it makes sense to ask for help, I think
this is a path worth taking.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:b1b79797-5cd0-643f-b045-58c5eefb6ec4@reagannetworks.com">
<p> </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>
</blockquote>
<p>We're currently evaluating options and migrating Thunderbird
add-ons to addons.thunderbird.net. We may choose to drop that in
the future given the AMO platform is a huge maintenance burden,
but for now we have a platform to do so.</p>
<p>As for reviewing, we will also reach out once we open reviewer
applications. Current Firefox reviewers will be asked if they want
to also handle reviews on addons.thunderbird.net</p>
<p><br>
</p>
<p>First things first though, we'll need to implement some APIs and
get it working before we can think about the add-on submission
process.</p>
<p>Philipp<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:b1b79797-5cd0-643f-b045-58c5eefb6ec4@reagannetworks.com">
<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:part10.E1B9E172.EDBF8F60@thunderbird.net"
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: 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" 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>
<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>
<p><br>
</p>
</body>
</html>