<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>