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