On Wed, Feb 06, 2019 at 11:31:20AM +0100, Michael de Boer wrote:
That looks really neat and a nice step forward! I’m a fan of
all the things you’re doing, btw ;-)
Cheers.
* Perhaps a link (or multiple links) to MDN docs we already
have on XPCOM components - which may provide an introduction as
to what they are, when and why they’re used, etc.
I'm not sure this is a good idea. Docs about Gecko internals on
MDN are generally deprecated, and the ones about XPCOM are
obsolete to the point of being useless.
I'm also a bit leery about mentioning old coding styles in docs
like this, since those kinds of mentions tend to stick around
long after everyone has forgotten that style ever really
existed...
* An example of ‘old style’ vs. ’new style’ xpcom definition,
perhaps even a ‘good’ vs. ‘bad’ - but there’s a negative
connotation there, which may not be preferred.
* A full example (prolly on a second page would be best), which
showcases the discrete steps to get from zero to hero. Err, I
mean new component.
I’m suggesting all this extra work, because I think it will
actually save you a lot in the future; rtfm is a very simple,
yet powerful response to all the queries you’re gonna get.
Again, I'm not sure the linked doc is really the best place for
such things, since the doc is meant to be permanent, and it
would get dated fast.
I can give examples in this thread, if you think it would be
useful. But given that I've already converted (or have pending
patches to convert) pretty much all of our old-style
registrations, it wasn't clear to me that it would.
On 5 Feb 2019, at 22:12, Kris Maglione <kmagli...@mozilla.com> wrote:
As of bug 1478124, the new preferred method for registering XPCOM components is
via static manifest files, as documented here:
https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html
And, as of bug 1524688, it will be the preferred method of defining JavaScript
components as well as native ones.
The primary motivation for this change is to decrease the amount of memory
(and, to a lesser extent, startup performance) overhead that component
registrations consume in content processes, which would not have been
acceptable in the post-Fission world. It has the side-benefit, though, of
making most registrations much more straightforward, requiring only a single
entry, in a single place, for each component.
Thank you to all of the reviewers who had to review a lot of very large patches
to make this possible, particularly Nathan Froyd, Eric Rahm, and Mike Conley,
on whom I dumped most of the biggest chunks.
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
All great truths begin as blasphemies.
--George Bernard Shaw
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
