<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 16-10-2019 16:34, Eyal Rozenberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:eb072942-f6b5-a300-9df6-ad3ffdcba280@technion.ac.il">
<blockquote type="cite" style="color: #000000;">For add-on authors
going forwards, there is of course also an option C (depending
on what the add-on does): work with us to integrate the
functionality into core. If the add-on is under the bug-fix
category this is certainly the way to go as no API for a bug-fix
would be in sight. In general we're happy to include
functionality provided it's of general usefulness.
<br>
</blockquote>
<br>
With respect - if this were to happen, it would essentially mean
giving up on Thunderbird's extensibility, either immediately or
within a short period of time. With no force pulling in favor of
access to Thunderbird's innards from overlaid JS code - I'm
willing to bet that would disappear pretty quickly. It's sort of a
"divide and conquer" strategy.
</blockquote>
<p>Sorry if that wasn't clear, but of course part of this is loosing
extensibility. You can't really have full extensibility in the
traditional way, except for as experiments.</p>
<p>Why would Thunderbird create an API for a useful thing *only* for
add-ons? If it's of general usefulness, it would be exposed in the
core application. This doesn't mean core should have everything:
there's still room for add-ons to cater for specialized use cases.</p>
<p> -Magnus<br>
</p>
</body>
</html>