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 <[email protected]> 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 <https://codereview.chromium.org/1118673002>, 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 -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
