On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez <m...@mykzilla.org> wrote:
> Nicholas Nethercote <n.netherc...@gmail.com>
> 2018 March 9 at 20:02
> What's your definition of XPCOM?
> 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.
That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
over the definition isn't really useful.
> I'm interested in what else it provides that makes it so indispensable.
> Indeed, but that doesn't tell me how much of XPCOM would remain essential
> to Firefox if we no longer used XPIDL.
I think a better framing of your question would be "what could we remove if
we removed XPIDL/XPConnect".
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.
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.
> 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).
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.
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.
> 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
> 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).
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.
dev-platform mailing list