<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Good question.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The current form of
<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> is more of a
technical reference than a guide, even with the intro at the top
which I improved a couple weeks ago. And as you say, for past
developers.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Perhaps it could be improved further,
but I have been advocating for a document that expands on that
intro and summarize the state of 60 and 61 that clarifies
recommendations for add-on authors. That probably means creating
an new document on wiki or MDN, perhaps drawing from past
postings, and updating a few places in existing MDN. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I know the subject matter is still
evolving, but if nothing else we should at least have a anchor
document(s).<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/21/2018 12:07 PM, David Reagan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bf8e853c-7e24-3404-029b-9d697f266acf@reagannetworks.com">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">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">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">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>
<p><br>
</p>
</body>
</html>