It would really, really awesome (IMHO) to put some extra effort into minimizing bindings divergences. I think there's already some good foundation laid in this regard in the form of Script* classes (look for bindings/(js|v8)/Script* files) . I was once imagining that we could split out code generation into: a) conversion/instantiation helper functions (these will be different for V8 and JSC) b) the actual bindings, written using Script* stuff and common for both engines. Then we could rewrite (weeeeee!) all of our custom bindings to use Script* as well and live happily ever after. :DG< On Wed, May 27, 2009 at 11:50 AM, David Levin <levin@google.com> wrote:

On Wed, May 27, 2009 at 11:47 AM, Adam Barth <abarth@webkit.org> wrote:

...

I've been doing some work recently in our JavaScript bindings.  As part of this work, I've noticed that WebCore/bindings/js and WebCore/bindings/v8 have drifted apart in some details.  It's kind of ridiculous that we have so much duplicated code in these two folders. We should try to re-organize our bindings to share as much code as possible.

1) Where should the common code live?  One option is to have:

WebCore/bindings/js  <--- common code WebCore/bindings/jsc  <--- JSC specific WebCore/bindings/v8  <--- V8 specific

2) How much should we try to share?  For example, we could have an abstracted notion of ArgList that works for both engines, or we could be happy to factor out common routines like createWindow

<http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDOMWindowCustom.cpp#L285>.

I presume Sam is a good contact for the JSC bindings.  Who's a good contact for the V8 bindings?

dglazkov

...

Thanks, Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

On Thu, May 28, 2009 at 3:07 AM, Maciej Stachowiak <mjs@apple.com> wrote:

1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result:

Oh, I didn't realize this was a sensitive issue.

   1.a) We're not super keen on refactorings that wouldn't be justified just for JSC itself. If there is shareable code that is easily factored out without adding otherwise needless abstraction or layers of indirection, that's fine, but we don't want to add indirection that would add any code complexity or runtime cost.

Sounds like we should look for easy wins that don't impose a cost on the JSC bindings. I'll investigate and propose a list of candidates.

   1.b) We couldn't commit to not breaking the v8 bindings when hacking on the shared layer, if there was one.

Yeah, my approach has been to test my patches in my Chromium tree as well, but that's certainly not feasible for folks who don't have a Chromium tree lying around.

2) My understanding is that the v8 bindings are not even fully merged into the WebKit tree yet - many pieces live externally in the Chromium repository. So we couldn't meaningfully maintain the v8 bindings even if we wanted to, and would have no good way to evaluate the soundness of the shared layer.

I'll follow up with dglazkov about seeing what the challenges are here.

Again, I am sure maintaining a second set of JS bindings is annoying, but the Chrome team felt it was worth the cost to have a separate JS engine, and committed to taking on the burden.

My concern is mostly that having identical behavior between the JSC and V8 bindings makes WebKit a more consistent platform for web developers, and the more consistent the platform, the better the economies of scale are for developers to make sure their site works properly in WebKit browsers. Thanks, Adam