Currently, extension bindings boil down to running a bunch of javascript in order to instantiate the necessary objects. There are a lot of problems with this:
- It's javascript, which means it's easy to tamper with by modifying global objects. We try to get around this by using safe practices and saving copies of objects and methods we need (SafeBuiltins), but it's still a bit of an arms race and easy to mess up.
- It's slow. Even though we lazily instantiate APIs, it's still a significant amount of work to generate a binding on a web page. You can see this by navigating to example.com with an extension that runs at document_start and uses an API, and then examining the trace. Much of the load time is devoted to generating that binding.
- We miss out on all the new hotness that happens in the world of blink bindings. Blink bindings are being optimized for speed, because they have to instantiate the whole web. Extension bindings are lagging behind and don't get any of these benefits.
It would be great if we could instead generate extension bindings directly using the blink bindings system. This will be a lot of work. For one thing, there are a ton of "custom bindings" (read: hand-written custom API behavior) written in JS that would probably need to be converted to C++ at some point (which should likely happen anyway). For another, since our bindings are generated from the schema json/idl files, we need a way of generating blink bindings code from that (or something analogous). There is a lot of generated bindings code already, but we'll need quite a bit more. Naturally, we'll also need a way for these two systems to live together cooperatively, at least for a time, because it will be impossible to convert all bindings at once. And this is also a great time to investigate changing the APIs to use mojo rather than a single IPC to rule them all, since each IPC will have a backing C++ object to handle call/response.
This is a meta tracking bug; we'll break this off into smaller pieces.
Design doc forthcoming.
Comment 1 by rdevlin....@chromium.org
, Oct 21 2016