<div dir="ltr">On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez <span dir="ltr"><<a href="mailto:myk@mykzilla.org" target="_blank">myk@mykzilla.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote style="border:0px none" type="cite">
<div style="margin:30px 25px 10px 25px" class="m_-7734811702588581013__pbConvHr"><div style="width:100%;border-top:2px solid #edf1f4;padding-top:10px"> <div style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%">
<a href="mailto:n.nethercote@gmail.com" style="color:#485664!important;padding-right:6px;font-weight:500;text-decoration:none!important" target="_blank">Nicholas Nethercote</a></div> <div style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:right"> <font color="#909AA4"><span style="padding-left:6px">2018
March 9 at 20:02</span></font></div> </div></div><span class="">
<div style="color:rgb(144,154,164);margin-left:24px;margin-right:24px" class="m_-7734811702588581013__pbConvBody"><div><br>What's
your definition of XPCOM?</div></div>
</span></blockquote>
This is basically what I'm asking Kris. I define it as the system that
Firefox uses to make intra- and inter-language calls between C++ and JS
via XPIDL and XPConnect.</div></blockquote><div><br></div><div><div class="gmail_quote">That's not
how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and the
name XPConnect means "connecting Javascript to XPCOM"). But quibbling
over the definition isn't really useful.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">I'm interested in what else it provides that
makes it so indispensable.</div></blockquote><div class="gmail_extra"><span class=""></span><br><span class=""></span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<br></span>
Indeed, but that doesn't tell me how much of XPCOM would remain
essential to Firefox if we no longer used XPIDL.<br></div></blockquote><div><br></div><div>I think a better framing of your question would be "what could we remove if we removed XPIDL/XPConnect".</div><div><br></div><div>The main platform feature that XPConnect relies upon is the interface inheritance hierarchy derived from nsISupports, including the QueryInterface method to bounce between them. Specifically, objects must implement an interface in that hierarchy to be reflected out-of-the-box by XPConnect. However, there are lots of bits of C++ code that use QueryInterface as well, which would be more work to change.</div><div><br></div><div>The nsISupports hierarchy doesn't really cost us anything per se, certainly not enough to justify the gargantuan task of trying to rip it out. Using it heavily for performance-critical things can be slow (virtual methods plus any QI overhead), but we should just fix those callsites when they come up.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
For example, XPCOM supports component registration and overriding at
runtime. But it isn't clear that Firefox needs those features, now that
it no longer supports XUL extensions (unless perhaps for system
extensions).<br></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">XPConnect's dependency on runtime component registration is limited to the platform objects we've implemented in JS. If we get rid of those, that dependency goes away.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Getting rid of contract-ids entirely would entail some light modification of XPConnect to provide a different way to instantiate platform objects from JS, but the lion's share of the work would be fixing all the code that's set up to work with the existing mechanism.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
And xpcom/ contains a ton of stuff, as you say. But it isn't clear how
much of it is core to XPCOM and how much just happens to live in that
directory.<br>
<br>
I'm not playing the devil's advocate. I'm genuinely curious about the
extent of XPCOM's feature set (and how well it aligns with Firefox's
current requirements).</div></blockquote><div><br></div><div>XPCOM is a not-very-well-delineated hodgepodge of mostly-independent things. We are free to modify or remove any pieces that are causing problems, provided someone can demonstrate that it's worthwhile.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
<br>
-myk<br>
<br>
</font></span></div>
</blockquote></div><br></div></div></div></div>