<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Let's rename "WebExtensions" to "MailExtensions" and
"WebExperiments" to "Addon API Experiments".</p>
<p>See below:<br>
</p>
<blockquote type="cite"
cite="mid:c38cfd81-8f4a-227a-30e5-5904ced336c3@beonex.com">
<p> </p>
<p>I think WebExperiments are a also great opportunity for
grass-roots action.</p>
<ol>
<li>Individual addon developers can implement an API that they
are lacking, and use it immediately in their addon, without
waiting for Thunderbird.</li>
<li>Then, they can generalize the API, make it generic for other
addons to use</li>
<li>They can propose the API for inclusion, and seasoned
developers can look over the API, improve it. (This step is
important to keep the public APIs consistent, generic, stable,
and of high quality.)<br>
</li>
<li>It's included in Thunderbird<br>
</li>
</ol>
</blockquote>
<p><br>
</p>
<p>All addon authors: This is your call to action!</p>
<p>Go and try to implement your addon as MailExtension. You will
miss APIs left and right, everywhere. But with "Addon API
Experiments", you have all the access that you have from a normal
restartless XPCOM addon (without XUL), and you can implement the
APIs you need. Then, proceed with the steps outlined above, and
other addon developers can benefit from it, and Thunderbird will
start to develop a stable (!) API surface for addons.</p>
<p>With stable addon APIs, the "my addon stopped working after
upgrade" should gradually stop as well.</p>
<p>Please don't expect somebody else to do it for you. The TB
Council or Core devs are too busy keeping Thunderbird running.
This is now up for the addon developers to do, bottom up, grass
roots fashion. Get your hands dirty and help!</p>
<p>FWIW, that's what we did with <a moz-do-not-send="true"
href="https://addons.thunderbird.net/thunderbird/addon/owl-for-exchange/">Owl</a>,
too.<br>
</p>
<p>Ben<br>
</p>
</body>
</html>