New top-level directory: Gin, a lightweight bindings system for V8

[Adam Barth]

Hi chromium-dev,

I recently landed a CL that created a new top-level directory named gin.  In this directory, Aaron and I are working on a library for creating light-weight bindings for V8.  In the near term, we plan to use this library to create JavaScript bindings for Mojo IPC.

Before gin, Chromium had two systems for creating V8 bindings: Blink's bindings and the Extension/Apps bindings.  (There are also two copies of CppBoundClass, which binds to JavaScript via NPAPI.)  In the long term, I would like to unify these two systems to reduce redundancy.  Unfortunately, both systems have disadvantages,  The Blink bindings are tightly coupled to Blink and the extension bindings are implemented via in JavaScript via v8::Extensions, which leaks implementation details.

In the long term, I hope that both the Extension bindings and the Blink bindings will be able to use Gin to bind to V8, but there's a long road between where we are today and that future.  In the near term, we plan to use Gin to build JavaScript bindings for Mojo's IPC system.  That application will let us incubate the bindings, learn from the experience, and hopefully evolve them towards being able to support all of Blink's and the Extension system's use cases.

Happy hacking!

Adam

[Jochen Eisinger]

Hey,

is there a issue where I can follow progress? Do you have concrete plans to switch over esp. the CppBoundClass based bindings anytime soon (or if not, mind if I start doing so?)

best

-jochen

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Adam Barth]

On Sun, Nov 10, 2013 at 11:20 AM, Jochen Eisinger <joc...@chromium.org> wrote:

is there a issue where I can follow progress?

I just created https://code.google.com/p/chromium/issues/detail?id=317398 to track building the JavaScript bindings for Mojo IPC.  We're currently using that to drive Gin development, so following that bug will give you a good sense what we're up to.

Do you have concrete plans to switch over esp. the CppBoundClass based bindings anytime soon (or if not, mind if I start doing so?)

I don't have any concrete plans to replace CppBoundClass, but that would certainly be valuable.  If you're interested, you're probably going to run into the following three complications:

1) Both Blink and Gin want to store per-isolate data with v8::Isolate::SetData, but there can only be one, highlander style.  One approach to solving this problem is to make WebCore::V8PerIsolateData inherit from gin::PerIsolateData and teach Gin that the embedder might be the one that calls v8::Isolate::SetData.

2) Blink assumes that it understands the structure of the internal fields of all V8 objects in its isolates.  Gin also uses internal fields with a similar structure to Blink, but the exact types aren't the same.  One approach to solving this problem is to make WebCore::WrapperTypeInfo inherit from gin::WrapperInfo.

3) From (1) and (2), you can see that using Gin in the same isolate as Blink means that we'll probably need to add a dependency from Blink on Gin.  We'll want that eventually if/when we migrate Blink to using Gin, but in the short term that introduces a cross-repo dependency from Blink to Chromium, which isn't fun.

In summary, I would very much like to replace CppBoundClass with Gin, but it's going to be easier after we merge the Chromium and Blink repositories.  If you see clever ways of solving these problems without cause cross-repo pain, feel free free to hack away.

Adam

[Jonathan Dixon]

> There are also two copies of CppBoundClass, which binds to JavaScript via NPAPI. 

Relatedly: what's the wider plan for the NP mechanism (NPChannelBase et al) with eventual NPAPI retirement in mind?

The Android JavaBridge also binds to JS via NPAPI (I believe CppBoundClass was held up as the template that its design should be based on).

We have a bug open to move the browser side of JavaBridge away from NP concepts. If the NP channel mechanism is being retired completely then JavaBridge will be in the market for a whole new JS->IPC->browser binding transport, and if I read this correctly, it sounds like we should look to Gin to provide that?

(Context: JavaBridge is used to implement the addJavascriptInterface() API on WebView, and also currently underpins accessibility in Chrome for Android)

Thanks,

PS why not "Gini"?   => Gini Is [Not|New] IDL   ;-)

[Jochen Eisinger]

For chromium, there's the following issue: http://crbug.com/297480

The big consumers are the testRunner and the automation controller. The rest can probably changed to another concept without much effort.

automation controller is supposed to go away soon, and I'd like to experiment with moving testRunner to gin.

At this point, we'd just delete CppBoundClass.

best

-jochen

[Aaron Boodman]

Bummer that Gin is taken, and the only other juice-related puns I can think of are inappropriate.

Gini it is.

- a

[Adam Barth]

On Sun, Nov 10, 2013 at 11:54 AM, Jonathan Dixon <jo...@chromium.org> wrote:

> There are also two copies of CppBoundClass, which binds to JavaScript via NPAPI. 

Relatedly: what's the wider plan for the NP mechanism (NPChannelBase et al) with eventual NPAPI retirement in mind?

We'd like to move away from using NPObject and friends, but realistically it's going to be a long time before we've removed all the clients.

The Android JavaBridge also binds to JS via NPAPI (I believe CppBoundClass was held up as the template that its design should be based on).

We have a bug open to move the browser side of JavaBridge away from NP concepts. If the NP channel mechanism is being retired completely then JavaBridge will be in the market for a whole new JS->IPC->browser binding transport, and if I read this correctly, it sounds like we should look to Gin to provide that?

Yes, Gini will likely be useful to you.  If you try to use it now, you're likely to run into the same issues I mentioned to Jochen upthread.  I certainly hope that Gini will be ready by the time we retire NPObject, which means the timeline will likely work out for you.

Adam

[Darin Fisher]

Note: pepper flash relies on npruntime (WebBindings) infrastructure as well.

[Jonathan Dixon]

On 10 November 2013 13:54, Adam Barth <aba...@chromium.org> wrote:

On Sun, Nov 10, 2013 at 11:54 AM, Jonathan Dixon <jo...@chromium.org> wrote:

> There are also two copies of CppBoundClass, which binds to JavaScript via NPAPI. 

Relatedly: what's the wider plan for the NP mechanism (NPChannelBase et al) with eventual NPAPI retirement in mind?

We'd like to move away from using NPObject and friends, but realistically it's going to be a long time before we've removed all the clients.

The Android JavaBridge also binds to JS via NPAPI (I believe CppBoundClass was held up as the template that its design should be based on).

We have a bug open to move the browser side of JavaBridge away from NP concepts. If the NP channel mechanism is being retired completely then JavaBridge will be in the market for a whole new JS->IPC->browser binding transport, and if I read this correctly, it sounds like we should look to Gin to provide that?

Yes, Gini will likely be useful to you.  If you try to use it now, you're likely to run into the same issues I mentioned to Jochen upthread.  I certainly hope that Gini will be ready by the time we retire NPObject, which means the timeline will likely work out for you.

Thanks! I made a note of this on crbug.com/258510

[Paweł Hajdan, Jr.]

By the way, this might be beyond scope, but for extension browser tests (and possibly more tests like webui browser tests) it'd greatly help stability IMHO to have good easy to use bindings to communicate between C++ test and JS running in the renderer.

I could obviously think about more specifics here, but maybe just that will give you some ideas or inspiration.

Looks like really good work here - thank you.

Paweł

[vchi...@yandex-team.ru]

Hello, chromium-dev,

Some little question in this old thread: Is there any plans to move extension bindings to gin? Is there any issue which is possible to follow for more information about this? 

Thank you in advance!