<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12/21/2016 8:08 AM, Disaster Master
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fd646012-783d-9378-14ce-608cdfeacbe7@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      So - <u><b>is XPCOM included with XUL/XBC in the above comment?</b></u><br>
      <br>
      Assuming it is, here is another important question.<br>
      <br>
      <u><b>Is it the removal of XUL/XBL(/XPCOM) from m-c that poses the
          imminent threat to TB, both from a UI and Addon perspective?</b></u><br>
      <br>
      <u><b>How long before XUL/XBL(/XPCOM) will actually be slated for
          removal from m-c? Is it possible to even get a rough estimate
          of a date?</b></u></blockquote>
    <br>
    Let me provide some historical perspective here. A large portion of
    the base platform of mozilla-central and comm-central essentially
    date back to the C++ Netscape rewrite in the late 1990s. In those
    days, portability was a major headache and libraries for managing
    portability didn't really exist, so Netscape did what made sense:
    they made their own. Thus was born XUL, XBL, XPCOM, NSPR, etc.<br>
    <br>
    The world of programming is not what it was 20 years ago. By the
    late 2000s, there was a reinvigorated effort to improve the quality
    of HTML, CSS, and JS. The newer features of these languages obviated
    the need for XUL and XBL (note that Mozilla's experience with XUL
    and XBL were considered as very significant prior arts in developing
    the newer standards). A side effect of the development of JS was the
    need to specify a dialect of interface descriptions for HTML that
    could better use the capabilities of JS--this dialect is WebIDL.
    Also concurrently, the C and C++ working groups started including
    more features in their standard library, and compiler writers caught
    up with implementing those standards, obviating the need for
    portability layers.<br>
    <br>
    Around 2010, there was consternation that the Mozilla codebase was
    too tied towards a weird dialect and that this turned off
    developers, and so some people advocated moving Mozilla towards
    idiomatic HTML/JS/CSS/C/C++ wherever possible. In the ongoing
    discussions, there has been agreement that features are too
    inherently deficient for our needs (std::string is an excellent
    example), but where that does not apply (e.g., uint64_t versus
    PRUint64), the use of more idiomatic coding styles should be
    preferred. There has also occasionally been comments that we
    shouldn't be supporting our weird, unnecessary duplications of
    standard features--and that's where you hear that X or Y is
    deprecated and should be removed.<br>
    <br>
    As for the timetable, consensus has yet to be achieved. Netscape is
    considered a classic example of how a rewrite can completely screw
    you over. Where mass changes can be easily done--say, PRBool to
    bool--many of them were; where they can be not--XUL box model to CSS
    box model, say--there is reluctance to move forward. The deprecation
    of the use of these technologies in add-ons is meant to be a step on
    the path to being able to do with them in their entirety eventually
    (it is easy to monitor all uses in mozilla-central to know when
    something can be removed, much harder in extensions), but eventually
    comes with no timetable. As they say, there is nothing so permanent
    as a temporary fix.<br>
    <br>
    To answer your questions for XPCOM in particular:<br>
    XPCOM means several different things, depending on who you talk to.
    The first is a C++ data structures/algorithms library, which is
    unlikely to go away (since most of these things have custom features
    that are needed in m-c), and for which any (breaking) changes are
    likely to be highly automated. The second bit is basically a giant
    service reflection mechanism--how random code knows how to get, say,
    the database service, or how to create an instance of an interface.
    This code is simple (it's basically a giant hashtable along with a
    collection of macros to implement extremely boilerplate code with
    lots of custom debugging hooks) and unlikely to change much or be
    removed anytime soon--it's too useful to get rid of, too pointless
    to reimplement in a different style.<br>
    <br>
    The other interpretations center on XPIDL, which is based on an
    implementation of interface description. The implementation in m-c
    is based on a reflection mechanism, with code generated via a tool
    so stable that I think I'm the only person to *think* about changing
    it in the past half-decade. All the complexity is in the reflection
    implementations: the Java and Python implementations didn't survive
    the added features around 2008-2010 (after WebIDL bindings were
    added, everyone stopped caring about the original tool). The C++
    side of the reflection library is similarly stable, if extremely
    obtuse to understand (it requires detailed ABI knowledge to attempt,
    and, like most attempts at reflection, requires keeping track of
    multiple things claiming to be "this"). It should be noted that the
    generated C++ is not "natural" to most modern C++--you know the,
    nsresult nsFoo::Bar(uint64_t *realResult) signatures, and this is
    what the contributor consternation has focused heavily on. The JS
    side (known as xpconnect) is the most complex portion, as it
    requires interfacing with ever-changing SpiderMonkey bindings and
    having to support halfway measures like nsIXPCScriptable or
    quickstubs or WebIDL bindings. As this is large, fragile, and
    difficult to maintain, I would expect this piece to be dropped the
    moment it's no longer needed.<br>
    <br>
    And when that might be? For all of the complaining and
    consternation, all of our I/O--particularly network I/O--is
    fundamentally centered on the
    nsIChannel/nsI{Async,}{Input,Output}Stream paradigm. And there's no
    clear paradigm in C++ or JS that's sufficiently standard to be worth
    replacing that implementation. Handling networking--particularly
    proxy settings and SSL interactions--is sufficiently complex and
    central to the way you express interfaces in the first place that
    there is unlikely to be a push to move this code to Rust any time
    soon.<br>
    <br>
    In short, XPCOM is unlikely to be removed anytime soon. XUL and XBL
    (even though I haven't discussed them) are similarly unlikely to
    disappear shortly. What you're seeing is a "try not to use this"
    sentiment, but there's no realistic path to deleting this stuff on
    any definite timetable.<br>
    <pre class="moz-signature" cols="72">-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code arch├Žologist</pre>
  </body>
</html>