<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
We had a long discussion about addons in Thunderbird at our group
meeting yesterday. We are trying to decide what we can say about our
current policy towards addons. This thread is part of the
information gathering for that.<br>
<br>
On binary extensions, we're pretty agreed that the policy stance is
this: We currently continue to accept binary extensions, and there
are several key binary extensions in our addon ecosystem. But they
are deprecated, mostly because with Firefox no longer accepting
them, there are likely to be breaking changes in core code that we
cannot overcome. Anyone with a binary extension needs a migration
plan away from that.<br>
<br>
It would be good to inform us of any binary extensions that are out
there and your needs. If there are core hooks needed to allow your
extension to function, we are pretty accommodating to that. Most of
my personal new development effort is going into adding addon hooks
to core for new account types, which are needed both for my own
ExQuilla binary extension, but also for the work we are doing to
incorporate other new protocols such as JMAP.<br>
<br>
Certainly binary extensions are and will continue to be allowed in
Thunderbird 38.* For our next major version, 45.*, the picture is
not clear yet, but I would hope yes. But probably not beyond that.<br>
<br>
The story is very similar with addon signing. That is, not required
in Thunderbird 38, not yet clear for Thunderbird 45 but probably
will not be required there, after that who knows.<br>
<br>
We have no current plan for dealing with the XUL deprecation issue.
We don't get invited to sit at the cool kids table anymore, so this
is hitting us about the same time it is hitting you (though I
suspect the discussion was public if we had looked hard enough).<br>
<br>
In the long run, I'm actually excited about the prospects of solving
all of the issues with HTML that would allow us to run Thunderbird
as pure HTML. That would give us the long-term hope of having a
product that could run outside of the Mozilla binary environment,
such as on mobile devices or as a pure web app. I actually think
this is likely in the long run to be more beneficial for Thunderbird
than for Firefox. But the work to get there is enormous, and we are
still trying to sort that.<br>
<br>
Concerning the effect of that on addons, whatever we do will
probably lag Firefox by about a year, and even for them I think the
situation is quite murky right now. We're just going to have to wait
and see what Firefox ends up doing to solve the extension problem,
adapt it if we can, if not we'll have to figure out something else.
I realize that that is not a particularly satisfying answer, but
Mozilla does not ask our permission before they make big public
announcements like this. We're still trying to formulate a position
that we can announce officially, even if that position just confirms
our uncertainty.<br>
<br>
At least for Thunderbird, we have no current intention of either
trying to reduce the power of addons, nor trying to be compatible
with some industry-wide standard for addons (since there is no
equivalent to "Web Extensions" for email clients). We're a different
product than Firefox with different needs. But the prospect of
trying to do our own thing here independent of Firefox would be
enormously challenging.<br>
<br>
:rkent<br>
<br>
<div class="moz-cite-prefix">On 8/26/2015 8:19 AM, Chris wrote:<br>
</div>
<blockquote cite="mid:55DDD8EB.5020403@birdiesync.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi,<br>
<br>
I work on BirdieSync software which synchronizes contacts,
events, and possibly tasks and mails between Android, iPhone,
Windows Mobile devices and Thunderbird. I'm concerned about the
last news about the possible evolutions regarding add-ons.
BirdieSync has a third-party add-on in Thunderbird which relies
on XPCOM and XUL through binary components, and uses the needed
XPCOM interfaces to access to contacts, calendars and mails.<br>
<br>
The new step of switching to another technology than XPCOM and
XUL for add-ons would be problematic at the least. If add-ons
would need to rely exclusively on WebExtensions API in the
future, it would mean a huge work having to fully rewrite the
add-on, and potential lacks in the new restricted API. For
instance, the API to connect with native applications is only
said to be "likely" offered by Mozilla and it would be necessary
to have a new dedicated API in Thunderbird to manage contacts,
calendars and mails, available to third-party developers.<br>
<br>
I hope that alternative solutions will be possible to continue
offerring access to XPCOM components in Thunderbird, also
through binary components. I'm aware that the decision of
continuing offering support of XUL and XPCOM add-ons may not
only depend on Thunderbird will and may depend on future Mozilla
Core evolutions. If it couldn't be possible, I only hope that it
would be at least feasible to achieve with the new API what was
possible with XPCOM.<br>
<br>
I will take the opportunity of this mail, to thank all the
Thunderbird team for the great job they do, their hard work and
involvement !<br>
<br>
Chris<br>
<br>
Le 8/24/2015 8:35 PM, R Kent James a écrit :<br>
</div>
<blockquote cite="mid:55DB63E7.50801@caspia.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
We need to do some sort of announcement in the Thunderbird blog
about our plans concerning addons. I'd like to have feedback
from folks to see if there is any debate about what is the
correct direction for us.<br>
<br>
We've at least agreed that we are continuing to support binary
addons. Concerning signing, we took steps months ago to not move
forward on requiring addons to be signed, so there are no
current plans to require signing. There is still some debate
about that in bug 1168571. We should probably come to a firm
decision and announce it. Most commenters were opposed to
signing, though there were some holdouts.<br>
<br>
Then there is "<a moz-do-not-send="true"
href="https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/">The
Future of Developing Firefox Add-ons - The Mozilla Blog</a>"
that announces the complete disabling of current XUL addons at
some point in the future. Several Thunderbird community members
commented on that blog post, strongly opposed to that direction.<br>
<br>
Contrast that with <a moz-do-not-send="true"
href="https://wiki.mozilla.org/Firefox/Go_Faster">Firefox/Go
Faster</a> where there are plans to expand the use of addons
in Firefox, adding so-called "system add-ons" and moving Hello
to one. (This is similar to what we are doing with Lightning,
which should hopefully make our Lightning integration easier in
the future).<br>
<br>
At this point, I think that the prevailing viewpoint is probably
the following, and I would like to announce this if possible in
a blog post:<br>
<br>
1) Thunderbird continues to support binary addons.<br>
2) Thunderbird will not require addon signing.<br>
3) Thunderbird has no current plans to disable the use of
traditional XUL/XPCOM addons in Thunderbird.<br>
<br>
This policy must be modified by the caveat "as long as core
Mozilla code can be used to support it".<br>
<br>
(I might also note that initial patches are being looked at for
the integration of the technology formerly know as Skinkglue
into Thunderbird core, to be called JsAccount, which makes it
possible to define new account types in Thunderbird using a
traditional XUL/XPCOM/JavaScript addon. This will almost
certainly be in our next major release).<br>
<br>
Could I have some comments or discussion on these proposed
positions?<br>
<br>
I hope the Thunderbird community appreciates that diverging from
Mozilla in this manner will probably mean that we will need to
take over addon review from Thunderbird at some point, possibly
including forking of AMO for our own use.<br>
<br>
:rkent<br>
</blockquote>
<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>