Re: JavaScript engines

[Robert Carr <carrr rpi edu>]

I just woke up to about 50 emails to reply to, so this might all come out 
rather disorganised, but this seemed like a good one to start with.

I appreciate Havoc's first point, in that I agree it's not fair to drop
the entire responsibility for re basing on the other binding on one
group. As both appeared around the same time period, and neither one has
had large amounts of adoption yet.

Obviously, gjs will not just go away (for Havoc's enumerated reasons). I
don't see Seed going away any time soon either, for a few of the
following reasons:
* I am planning to use Seed in an app I am working on (will release
eventually :P), which is already using WebKit.
* Epiphany developers have expressed more interest in migrating to Seed
for extensions (should be some proof of concept code for that in a few
days), and of course epiphany is using WebKit now.
* Seed is approaching the point where it goes in to "maintenance" mode,
and should by and large have the first (I suppose it could be called the
second) batch of features complete within the next few weeks, so I will
of course continue to maintain it.

I 100% agree developing a common C API makes sense. This API would have
to be somewhat limited compared to the full SpiderMonkey/Seed (Seed API
does not expose JavaScriptCore) API, but could probably cover common
embedding situations. I am not sure an abstraction layer good enough to
support the C extension modules is actually feasible, due to the large
differences (C API wise) in the class definition mechanisms, and GC
semantics. In addition some of the rules on how you can keep C JSContext
refs around, are different (I seem to recall some uses of this, which I
know would NOT work in WebKit). Then WebKit also has the whole
JSContextGroupRef semantic, related to Contexts which can share objects,
so I don't know how spidermonkey does this.

As for JS level compatibility, the primary issues there are as follows: 
* Small binding details (i.e. different enum casing). I am willing to
change things like this immediately (today?).
* gjs/spidermonkey use of let statements. WebKit is open to a patch
adding let statements, but it is not one of their priorities...my
attempts at this turned out to not be the best approach, and I don't want 
to commit to trying to get a version of this upstream, but it's likely
I'll try again some point soon.
* Seed features GJS does not have: Seed supports a lot of things GJS does 
not, including GObject Subclassing, with new properties/signals
(implementing interfaces/abstract methods  also "works" but is blocking
on a gobject-introspection bug). Some others are, automatic boxing of JS
functions in to C function pointers (from libffi), so that functions like 
gtk_container_foreach work. I believe Seed has somewhat more complete
struct/boxed integration (a nice struct literal syntax, etc...), though I 
will confess to not having looked at Gjs in a while here. Seed also has
lots of corner cases fixed that I have not seen done in Gio (the Seed
examples cover a fairly large portion of mainstream GObject libraries,
and it's let us hit a lot of the issues). All of these are made quite
pervasive use of in Seed code, and are also quite useful, and so I do not 
want to just drop them. There is no obvious technical reason why most of
these could not be implemented in gjs (though they are nontrivial...),
and I would be willing to help, or change some of the specific semantics
of how these things work in Seed, however I can't commit to doing ALL of
them in gjs. If these features don't make sense in gjs, Seed could easily 
be made a superset of gjs, with the rest of the API binding identically.

The in-one-repository approach with work on a shared test suite (covering 
at least the subset of things we can agree on now, e.g. basic binding
stuff), and a least-common-denominator C API, both make sense to me. In
addition we need to find out the differences in the core binding
semantics/builtins, and maybe start to work out some things there.

How would you like to go about doing this?

Thanks,
Robert
==============Original message text===============
On Tue, 06 Jan 2009 14:38:17 EST "Havoc Pennington" wrote:

Hi,

On Tue, Jan 6, 2009 at 2:07 PM, Jason D. Clinton <me jasonclinton com> wrote:
> On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson <alexl redhat com> wrote:
>> The APIs will certainly not automatically be the same. There are lots
>> and lots of little decisions you have to make when you bind gtk. If just
>> one of these differ then they won't be compatible.
>
> It's not clear to me why this would not be considered a bug.
>
> Hopefully Robert will jump in here and say he's willing to treat GJS
> as the reference implementation and then everyone can just be happy
> with two implementations with the same API on which any app can Just
> Work.
>

Well, I would be reluctant to put this all on Robert. There's no real
a priori reason seed should copy gjs instead of vice versa. The two
projects started at roughly the same time with no awareness of each
other.

As a practical matter, the litl app is a huge amount of of gjs code,
so there is no way we can port it to another setup anytime soon (which
does not necessarily govern gjs upstream, but if gjs were incompatibly
changed, we would probably end up keeping a branch that wasn't
changed). So that is a practical consideration for the people working
on gjs at litl, otherwise I might offer to be "seed compatible."
Realistically speaking we need something gjs compatible for quite a
while.

But, I don't know about trying to hash out seed vs. gjs on the mailing
list. They both have pros and cons, both have people excited about
working on them, neither one is a "fork" that post-dates the other; so
it's kind of a  mess, but there isn't a clear right answer and it's
not anybody's fault for creating it.

If someone, through hacking, were going to clean it up; I would suggest:

- move them into one module with webkit and spidermonkey subdirs
- have a single test suite covering module system, gobject binding
conventions, etc. and make both pass it
- use a common C embed API like alexl's gscript one (also with test
suite coverage)

But this is pretty complex in some ways:

- if as Tim says, webkit lacks "let", that's a pretty huge issue
("let" is one of the ways gjs-javascript is far less annoying than
browser-javascript).
  it'd require a big downgrade to go least-common-denominator on this.
- gjs allows 'native modules' written in C, those use spidermonkey
APIs directly; an abstraction layer good enough to support this would
be a lot of work
- undoubtedly a number of other little things

Anyway, working on reconciling the APIs through some sort of shared
test suite and C gscript API is probably more productive than mailing
list traffic, so perhaps we need a volunteer on that front.

Havoc
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
===========End of original message text===========