Re: New Module Proposal. libseed

[Robert Carr <carrr rpi edu>]

On Wed, May 13, 2009 at 6:31 PM, Havoc Pennington
<havoc pennington gmail com> wrote:
> Hi,
>
> fwiw, I think there's actually a (reasonably) sane way to support
> multiple JS engines, which we've discussed.
>
> The practical path is:
>
>  * have same module system for both engines (done, thanks to robert)
>  * ideally, add "let" support to webkit (which would be good anyway)
>  * add to gnome-js-common the written-in-JS modules from seed and gjs
>  * add to gnome-js-common the test suite for said modules, which is
>    fairly thorough
>
> Basically the point is to have a common set of modules written in JS,
> and a common test suite. And then gjs and seed separately provide the
> native code stuff, but having to pass the same test suite.
>
> To make it practical, the gnome-js-common stuff would have to support
> selectively disabling stuff that wasn't implemented for one runtime or
> the other yet.
>
> Anyway, I don't know if anyone will do this, but I don't think it's
> that challenging, and it has some positives. It has some downsides
> also.
>
> The biggest positive in my mind is basically that open source projects
> tend to be a lot better if more people use them, and there are reasons
> for people to choose various JS engines, and no real reason to
> implement something like the dbus bindings separately for each. I
> think Seed has benefited quite a lot from sharing code like the module
> system and dbus bindings from gjs. But right now seed takes that stuff
> and then forks it off, there isn't a common upstream place to put
> code.
>
> One negative is that it's extra work, and another is that new
> contributors might not know which runtime to choose; though if they
> are compatible, maybe that isn't a huge deal anyhow.
>
> gnome-js-common could be the right decision even if gnome includes
> only one of the runtimes, just to get more people hacking on the suite
> of JS modules.
>
> Havoc


I've started the gnome-js-common module tonight and pushed it to GIT
(just lang.js signals.js and tweener), and by the next Seed release (2
weeks again...) intend to move a lot of the Seed modules and tests
there. I'm going to move the Seed modules with no GJS counterpart
(canvas, libxml, os, readline, sandbox, sqlite), there also, and put
stuff in the build system for GJS implementations if anyone at some
point wants to do any of that. Most of them have their API documented
(and the ones that don't, have documentation elsewhere, like os), so
it would be pretty easy to have implementations in sync.  I will try
and copy some of the GJS tests also.

In general I don't really know how much code can be shared for modules
that require C bits, the C API for SpiderMonkey and JSCore is pretty
different, so for simple stuff, some of the C code can look similar
(like the simple parts of the DBus bindings, is pretty much a direct
port of the GJS code), however for things like the DBus exports, or
the imports system, it made a lot more sense to just reimplement it in
a more JSCoreish way. So, for example the DBus bindings will have
around 3500 lines of code (per runtime) not shared, and around 600
shared. I also think porting from JSCore to SpiderMonkey C code will
require a little more effort in some cases, as SpiderMonkey seems to
require a lot more micromanagement of the GC.

Regardless, I still think it will be good to have it in a common
place, have common tests, modules, etc. It might even make a sense to
move some documentation and examples here.

Robb