<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<div id="smartTemplate4-template">Just some answers from my
perspective as a (mostly Thunderbird) XUL Addons developer<br>
</div>
<div id="smartTemplate4-quoteHeader">
<style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>Re:
What happened to hiring an architect?<br>
<b>From:</b>Disaster Master
<a class="moz-txt-link-rfc2396E" href="mailto:disasterlistmanager@gmail.com"><disasterlistmanager@gmail.com></a><br>
<b>To:</b>Tb-planning <br>
<b>Sent: </b>Friday, 16/12/2016 13:57:04 13:57 GMT ST +0000
[Week 50]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite"
id="mid_e0ec7620_13d1_ea60_3e42_234b967471cf_gmail_com"
cite="mid:e0ec7620-13d1-ea60-3e42-234b967471cf@gmail.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 12/15/2016 5:00 PM, <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:aleth@instantbird.org">aleth@instantbird.org</a>
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:aleth@instantbird.org"><aleth@instantbird.org></a>
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_1481839258_510126_820518609_3D4FA62F_webmail_messagingengine_com"
cite="mid:1481839258.510126.820518609.3D4FA62F@webmail.messagingengine.com"
type="cite">
<pre wrap="">I'm not aware of any timetable for removing XUL/XBL from m-c.</pre>
</blockquote>
<br>
Ok, clarification on this situation is sorely needed...<br>
<br>
First - a quick google reveals that XBL is apparently a sister
language to XUL - but what about XPCOM? It is just as (or more?)
important as XUL isn't it?<br>
</blockquote>
<p>If there is a replacement technogoly for XUL overlays (as in:
HTML overlays? anyone?) then I would say, yes XPCOM is much more
important. However overlaying is a really important way of
augmenting the UI in a deep way _quickly_. You can certainly do
this through DOM manipulation (e.g. inject a button at a time) but
there is a much higher "design threshold".</p>
<p>As regards XPCOM, that'sss an absolute essential for low level
access to objects that aren't exposed such as the ones listed
here:</p>
<p><a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface">https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface</a></p>
<p>Here is what I use in Thunderbird for just one of my Addons
(quickFilters) :<br>
</p>
<pre>
nsIAlertsService
nsIAppShellService
nsIClipboardHelper
nsICollection
nsIConsoleService
nsIDOMElement
nsIEditor
nsIExtensionManager (I know it's deprecated, just using it for older applications for backwards compatibility)
nsIExternalProtocolService
nsIFileInputStream
nsIFileOutputStream
nsIFilePicker
nsIFileURL
nsIFocusManager
nsIInterfaceRequestor
nsIIOService
nsIIOService
nsILocalFile
nsIMsgAccount
nsIMsgAccountManager
nsIMsgCompFields
nsIMsgCopyService
nsIMsgDBHdr
nsIMsgFilterList
nsIMsgFolder
nsIMsgGlobalIndex
nsIMsgHeaderParser
nsIMsgIdentity
nsIMsgIncomingServer
nsIMutableArray
nsIObserverService
nsIPrefBranch
nsIPromptService
nsIProperties
nsIRDFResource
nsIScriptableUnicodeConverter
nsIScriptError
nsIStringBundleService
nsIStyleSheetService
nsISupportsArray
nsISupportsString
nsITransferable
nsITreeBoxObject
nsIURI
nsIUrlListener
nsIVersionComparator
nsIWindowMediator
nsIWindowWatcher
nsIXMLHttpRequest
nsIXULAppInf
</pre>
<p>so that's just for a single Addon. If they were pulled I would
have to look for suitable APIs, and then do a <i>lot </i>of
rewriting. If some were not supported in APIs I would have ti
abandon functionality, to the point where the Addon might become
so lightweight that it wouldn't warrant the installation. So in my
mind XPCOM is indispensable right now. I can do the same search on
my Firefox Addons, and there would be probably a smaller list of
XPCOM interfaces but they would also most likelly be even more
substantial for their functionality.<br>
<br>
</p>
<blockquote class=" cite"
id="mid_e0ec7620_13d1_ea60_3e42_234b967471cf_gmail_com"
cite="mid:e0ec7620-13d1-ea60-3e42-234b967471cf@gmail.com"
type="cite"> Also - are XUL/XPCOM an integral part of Gecko? Or
are they separate?<br>
<br>
<blockquote class=" cite"
id="mid_1481839258_510126_820518609_3D4FA62F_webmail_messagingengine_com"
cite="mid:1481839258.510126.820518609.3D4FA62F@webmail.messagingengine.com"
type="cite">
<pre wrap="">What *has* been announced is the depreciation of non-webextension addons in Firefox
from Firefox 57 onwards
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/">https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/</a>), but since
XUL itself is not going away, keeping them working in Thunderbird beyond
that point should be feasible.
</pre>
</blockquote>
<br>
What was meant then by Mozilla's announcement of the deprecation
of XUL/XBL/XPCOM? Either they are going away, or they aren't. Or
maybe, they will be there, but the hooks will be removed for
Firefox? </blockquote>
<p>Don't worry, we Addon developers don't know either. I guess we
are just waiting for the day our Addons stop working (that happens
from time to timee anyway) and find out that we cannot repair them
anymore because the available underlying technologies have been
"locked down". <br>
</p>
<p>At the moment the process for use Addon Devs is fairly
straightforward: if a _single_ XPCOM interface is deprecated /
removed, our beta users usually file a bug in our Addons
bug-trackers and then we find the newer / workaround XPCOM
interface; I usually fix stuff within 24 hours of reporting. <br>
</p>
<p>Of course if all XPCOM interfaces become _verboten_ we are simply
royally fucked. In my case I will start advocating for the use of
Pale Moon. If it happens in Thunderbird I will begrudgingly
retreat to the Postbox code base (and keep hoping that there is
some sanity in the SeaMonkey crowd, which most likely is going to
fork) and kiss any potential income goodbye (Postbox is bad for
monetisation, their Addon Dev support is sketchy to put it very
very mldly). But I think on that front we will be safe until
Thunderbird council finally decides on whether they must fork, or
not.<br>
</p>
<p>hth,<br>
Axel<br>
</p>
<br>
<br>
</body>
</html>