Splitting SpiderMonkey out of libevil

Discussions about the development and maturation of the platform code (UXP).
Warning: may contain highly-technical topics.

Moderators: trava90, athenian200

Andrew Herbert

Splitting SpiderMonkey out of libevil

Unread post by Andrew Herbert » 2020-06-29, 15:57

Context: viewtopic.php?f=46&t=24662

Maybe DOM agnosticism could be leveraged to split SpiderMonkey out of libevil?

New Tobin Paradigm

Re: Splitting SpiderMonkey out of libevil

Unread post by New Tobin Paradigm » 2020-06-29, 16:16

This is one of the first UXP Issues I created. It is blocked currently by de-unified sources work.

Historically, Spidermonkey was considered a seperate project (can still be build standalone) and the rest of the codebase would talk to it through XPConnect an XPCOM host interface into JS. This is still the case.

HOWEVER, over the past decade to 12 years DOM was given its own direct native path that instead of using XPCOM making DOM its own "host application" to Spidermonkey. They did this to bypass XPCOM and improve speed and shit.

The problem is that because of using the JSapi directly and not XPConnect via XPCOM, DOM is completely hard dependent on on the exact implementation of the JSapi and not simply the interfaces of XPConnect.

So we COULD theoreticaly swap Spidermonkey out and use V8 writing a new XPConnect and adding what ever specific bits and bobs that are mozspecific and that would work great.. Except DOM would just about have to be rewritten from scratch because it uses the native JSapi directly soooooooo. Yeah.

Anyway, hope this helps with understanding.

Locked