<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/26/2015 02:44 PM, R Kent James
wrote:<br>
</div>
<blockquote cite="mid:55DE172C.1080104@caspia.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
It would be good to inform us of any binary extensions that are
out there and your needs.</blockquote>
<br>
This is extremely crucial advice to add-on developers. Anything that
cannot be satisfied with js-ctypes we should be well-informed of,
because we're unlikely to be able to maintain this.<br>
<blockquote cite="mid:55DE172C.1080104@caspia.com" type="cite">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>
</blockquote>
<br>
In a recent message, I've referred to the XUL/XPCOM issue as a
"looming disaster" (to steal the term from a video game). XUL we're
going to have to move away from, for sure. I do suspect, however,
that there will remain a chrome/content divergence in the layout
engine without HTML, and if that is the case, we should be able to
use WebIDL to bridge JS and C++ in a post-XPCOM world (I already
know at a high-level what needs to be done, and I've had support
from bz about our use cases here in the past). I do have ideas on
how to do that. It's very unclear to me how WebExtensions would
handle custom WebIDL APIs, but if that is possible, we could use it.<br>
<br>
The bigger problem with the deletion of XUL is that XUL has some
high-quality widgets that are very difficult to code in pure
HTML--namely, I'm referring to the <tree> widget. Honestly,
this is something that I feel Mozilla should be providing if they
move away from XUL, but I doubt they will (judging from the response
to the last XUL tree question on m.d.platform).<br>
<br>
<blockquote cite="mid:55DE172C.1080104@caspia.com" type="cite"> 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>
</blockquote>
<br>
There are some extensions for FF that do things like add new
protocol handlers whose support would require some sort of hooks
that we could likely abuse/twist for our ends. Some of the
documentation makes it clear that the add-ons team has no answers
for these questions (nor even really considered them too hard). This
makes proactive damage control extremely difficult on our end (or
even for many/most add-on authors).<br>
</body>
</html>