<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On 21. Apr 2018, at 6:43 PM, Axel Grude <<a href="mailto:axel.grude@gmail.com">axel.grude@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
<div id="smartTemplate4-template">
<p>Dear Philipp,</p>
<p>
</p><blockquote type="cite">
<pre wrap="">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.</pre>
</blockquote>
<p></p>
<p>this is excellent news. We really don't mind adapting to the
changes, but that is a lot better than taking away XPCOM and
overlays completely. Let there be some pain! :)</p></div></div></blockquote><div><br></div><br><blockquote type="cite"><div><div id="smartTemplate4-template">
<p>
</p><blockquote type="cite">
<pre wrap="">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.</pre>
</blockquote>
At which stage there will be an obvious choice to make for
Add-on developers: rewrite (and take a lot of functional loss
plus many months of work) or fork Thunderbird (if that is a
legal option). I know Waterfox didn't exactly set out with this
goal but it happens to be the only alternative for many Addon
authors who want a half way up to date code base.</div></div></blockquote><div><br></div>I think this is a decision that the add-on developer needs to take much earlier. It seems to me you are averse to doing a full rewrite.<div><br></div><div>No matter what tech is used, if you don’t go with changes you will eventually have to do a complete rewrite anyway.<div><br></div><div>If you are already gradually adapting your code to gecko changes, you could just as well adapt to writing new WebExtension APIs. If you do that in small pieces over time, you’ll never need to do a full rewrite.</div><div><br></div><div>Keeping the license terms in mind anyone can of course fork Thunderbird, but I’d much rather have those who would do so work with the Thunderbird community to improve the APIs we introduce. Again, anything that dwells on the old tech is spending a lot of resources to stand still.<br><blockquote type="cite"><div><div id="smartTemplate4-template"><p></p>
<p>
</p><blockquote type="cite">
<pre wrap="">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.
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.</pre>
</blockquote>
I don't understand everything fully, but please keep us
informed. Ray wanted to set up a weekly Add-on developers talk
on google, I think this would be an excellent platform to
discuss these newer technologies.</div></div></blockquote><div><br></div>I will most certainly keep folks informed about my progress!<br><blockquote type="cite"><div><div id="smartTemplate4-template"><p></p>
<p>
</p><blockquote type="cite">
<pre wrap="">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.
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</pre>
</blockquote>
I would definitely like to help there I would need some wrappers
for XPCOM interfaces I currently use many many times:<br>
<p></p>
<p><tt>nsIMsgComposeService, nsIClipboard,nsIWindowMediator,
nsIWindowWatcher, nsITransferable (for drag & drop),
nsIFolderListener, nsIMsgSearchSession, nsILocalFile /
nsIFile, nsIMsgFolder, </tt><tt><tt>nsIMsgDBHdr, </tt>nsIMsgFilterList,
nsIMsgIncomingServer, nsIPromptService, nsIMsgGlobalIndex,
nsITreeBoxObject, nsIURI, nsIMsgAccountManager, nsIMsgAccount,
nsIFilePicker, nsIFocusManager, nsIStyleSheetService,
nsIMsgMailSession, nsIXULAppInfo, nsIXULRuntime,
nsIRDFResource, nsIMsgCopyService, nsIConsoleService,
nsIScriptError, nsIExternalProtocolService,
nsIObserverService, nsIImapIncomingServer, nsIUrlListener,
nsIMsgFilter, nsIMsgRuleAction, nsIMsgSearchTerm,
nsIVersionComparator, nsIMsgHeaderParser, nsIMsgTagService</tt><br>
</p>
<p>a lot of these interfaces may already be covered by APIs, I do
not know because I did not start simply rewriting based on a
hunch that I may need to learn these technologies in mail.</p>
<p>If these interfaces go away for scripting will they also not be
used by the internal code base of Thunderbird (is Thunderbird
forced to eat their own dog food and use the APIs as well)? I
think this would ensure a full coverage of all needed APIs on
the rewrite.<br></p></div></div></blockquote><div>Instead of breaking this down to the exact interface used I think it makes more sense to collect high level use cases. From your list for example, I could see:</div><div>- ability to create new windows and observe windows opened (browser.windows.*)</div><div>- interact with the clipboard (might work already using the html5 clipboard api, could be that we need “content scripts” though)</div><div>- getting platform info (browser.runtime.*)</div><div>-logging to the error console (console.log)</div><div><br></div><div>The following don’t exist yet;</div><div>-searching and otherwise interacting with messages, folders and accounts </div><div>- access to filtering incoming emails </div><div><br></div><div>Philipp </div><blockquote type="cite"><div><div id="smartTemplate4-template"><p>
</p>
<p>Axel<br>
</p>
<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 <thunderbird_blog2.png>
</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>Philipp Kewisch <a class="moz-txt-link-rfc2396E" href="mailto:kewisch@thunderbird.net"><kewisch@thunderbird.net></a><br>
<b>To:</b>Thunderbird Planning (Moderated) <br>
<b>Sent: </b>Saturday, 21/04/2018 16:27:26 16:27 GMT ST +0100
[Week 16]<br>
</div>
</blockquote>
</div>
<blockquote type="cite" cite="mid:A2F49B29-C4D9-4B45-A37F-61E2AF97BAC5@thunderbird.net" id="mid_A2F49B29_C4D9_4B45_A37F_61E2AF97BAC5_thunderbird_net" class=" cite">
<pre wrap="">Hi folks
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.
We are experimenting with various approaches for extension authors to continue to maintain their add-ons with only minimal migration effort.
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.
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.
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.
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.
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.
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.
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.
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.
Philipp
> 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:
>
> 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.
> 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.
>
> -Magnus
>
>> On 21-04-2018 16:53, Axel Grude wrote:
>> 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.
> _______________________________________________
> 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>
_______________________________________________
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>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>tb-planning mailing list</span><br><span><a href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a></span><br><span><a href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a></span><br></div></blockquote></div></div></body></html>