Removal of XUL/XBC(?XPCOM? from m-c? WAS Re: What happened to hiring an architect?

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Tue Dec 27 22:59:27 UTC 2016


On 12/21/2016 8:08 AM, Disaster Master wrote:
> So - _*is XPCOM included with XUL/XBC in the above comment?*_
>
> Assuming it is, here is another important question.
>
> _*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?*_
>
> _*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?*_

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.

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.

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.

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.

To answer your questions for XPCOM in particular:
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.

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.

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.

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.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161227/97ed518a/attachment.html>


More information about the tb-planning mailing list