> > This sounds pretty great, but I'm also curious about the relationship > to Blink-in-JS.
I'm curious about this as well -- in more general, I'm curious about how we're going to layer the web platform. Here's my understanding; correct me if I'm wrong. - V8 extras and Blink-in-JS are aiming at different goals. - Blink-in-JS is aiming at implementing WebIDL features on top of existing Web APIs. Thus we don't want to add any "backdoor"s to the Web APIs, since those backdoors will break the layering philosophy of Blink-in-JS and make it harder to port the implementation to other vendors. - V8 extras is not directly related to WebIDL and is a more intrusive way to implement any feature using JS (instead of C++). For example, you can implement streams etc in V8 extras. If the streams.js needs to interact with C++, you can just expose V8 APIs for the interactions and the binding layer to connect the V8 APIs with the C++ (e.g., V8Streams class that abstracts the V8 APIs etc). From the viewpoint of Blink, the feature implemented by V8 extras will just look like other features in V8 -- in other words, there are V8 APIs to interact with the feature and Blink can just use the V8 APIs through the binding layer. This is a layering technology inside Chromium and it is not planned to port the JS implementation to other vendors. (I also want to see a design document of V8 extras.) On Tue, May 12, 2015 at 8:43 PM, Philip Jägenstedt <phil...@opera.com> wrote: > This sounds pretty great, but I'm also curious about the relationship > to Blink-in-JS. > > I poke at our <video controls> implementation in C++ from time to time > and it's just screaming out to be rewritten in JavaScript, so I'd like > to know if V8 extras might be useful for that. What's needed is a way > for C++ to hand a video element and an empty container to external > JavaScript code that would add controls to the container and hook up > the events. > > On Tue, May 12, 2015 at 2:20 AM, Kentaro Hara <hara...@chromium.org> > wrote: > > Is the V8 extras going to be used for features that can completely > > implemented on top of JavaScript and already existing DOM APIs? Or do you > > have a plan to make the V8 extras interact with C++ DOM somehow? (If so, > I'm > > curious how you're going to implement the binding layer.) > > > > > > > > On Tue, May 12, 2015 at 3:52 AM, Domenic Denicola <d...@domenic.me> wrote: > >> > >> Over the last two weeks we’ve been working on a new feature designed for > >> V8 embedders, called “V8 extras.” The intent is to allow embedders to > write > >> self-hosted (i.e. JavaScript) implementations of various features, with > more > >> power and less drawbacks than the existing V8 extensions mechanism. > Notably, > >> we are building on top of recent snapshotting work to ensure that the > code > >> for V8 extras is included in the snapshot, and so should not have > negative > >> impact on context startup time. > >> > >> You can see a working, albeit in-progress, example of a V8 extra in this > >> CL, which uses them to implement readable streams from the Streams > Standard. > >> General features on display include: > >> > >> The inclusion of the extras via the v8_extra_library_files GYP variable > >> The use of V8 native functions, such as %CreatePrivateOwnSymbol, in the > >> .js files (but see below) > >> The use of the extrasExports object to export functions and values to > the > >> embedder. This object can be accessed through the V8 C++ API with > >> v8::Context::GetExtrasExportsObject(). > >> > >> There are a number of changes we’re still working on implementing before > >> we could comfortably say that this feature is ready: > >> > >> We do not want to allow extras direct access to V8 native functions, but > >> instead only to a small number of pre-specified ones. The details on > how to > >> do this are still being worked out, but it will probably involve a > slight > >> change to the authoring format of the extras files, to become e.g. > script > >> whose completion value is a function that gets such a utility object > passed > >> in. > >> We need a story for segregating “experimental” extras from shipping > ones, > >> similar to what is being done in V8 already for harmony features. > >> Experimental extras cannot live in the snapshot, since they must be > able to > >> be turned off at runtime, while shipping ones will be compiled in. > >> We eventually want to expose an easy way for the embedder to supply > >> functions or values to the extras code. This is not actually needed for > >> streams, but for example if we were to implement something like > TextEncoder > >> or URL as an extra, it would be crucial. > >> > >> Overall though, we are quite excited about the possibilities this opens > >> up, by allowing embedders a performant way to implement features in > >> JavaScript. > >> > >> Best, > >> > >> Domenic Denicola > >> Jochen Eisinger > >> Yang Guo > > > > > > > > > > -- > > Kentaro Hara, Tokyo, Japan > > > > To unsubscribe from this group and stop receiving emails from it, send an > > email to blink-dev+unsubscr...@chromium.org. > -- Kentaro Hara, Tokyo, Japan -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
