Splitting SpiderMonkey out of libevil

Discussions about the development and maturation of the Unified XUL Platform (UXP).
Warning: may contain highly-technical topics.

Moderator: trava90

Post Reply
User avatar
Andrew Herbert
Fanatic
Fanatic
Posts: 155
Joined: 2019-11-25, 21:46

Splitting SpiderMonkey out of libevil

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?

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 7805
Joined: 2012-10-09, 19:37
Location: Space, maybe..

Re: Splitting SpiderMonkey out of libevil

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.
Image
- RIGHT, L2, DOWN, R1, LEFT, LEFT, R1, L1, L2, L1 is painless. -

Image

Post Reply