On Friday, November 11, 2016 at 2:05:28 AM UTC-8, Paul Rouget wrote: > We would like a Servo-specific embedding API, designed in a way that: > - it is optimised for Servo (we don't want to be limited by the webkit > or gecko legacy)
For Quantum, I've thinking about a new embedding API, and there's a use case for embedding both Quantum and Blink (as well as both Quantum and Servo), so I'd like to harmonize Quantum APIs with Blink (and Servo) equivalents to the extent possible. I'm curious to understand more about the WebKit/Gecko limitations you're trying to avoid. > - it is Rust-first. Then bindings for JavaScript and any other popular > language That makes sense, given that Servo is implemented in Rust. I'm not familiar with the state of Rust to C++ bindings, but presumably that's the easy part of creating a C++ binding that looks like Quantum's or Blink's API. The harder part is harmonizing the API concepts. > - it doesn't bend existing web standards and pollute the code base By this do you mean primarily mozbrowser, or are there other issues with existing embedding APIs that you're looking to avoid? > - it doesn't make assumption about how a web browser (the application) > is supposed to be working. A next-gen browser might want to go beyond > the regular urlbar+tabstrip design > - it delegates as much as possible to the embedder. Separation of > concerns: Servo renders web content. The rest is up to the embedder Right, this makes perfect sense, especially since there are a variety of use cases for embedding a rendering engine, and they aren't all browsers. There may be some complexity to determining which specific parts of the browser belong in the engine versus the embedder, but this is a good guiding principle. It'll also be easier to pull parts into the engine later than to pull them out of it. > - give deeper access to the engine, especially to the compositor and > events management I'm not familiar with the use cases for this, but from the proposal, it sounds like you want to do some interesting experiments on a browser interface. Seems reasonable, although I wonder if there's an abstraction for the common cases of rendering some content in a rectangle. > I have also outlined a possible way of implementing a JS API as a > third-party project: > https://github.com/paulrouget/servo-embedding-api/blob/master/JS_API.md Would you be interested in using SpiderNode as this runtime? We used in Positron to run Electron's Node modules and are now experimenting with using in Firefox to enable WebExtensions to spawn Node child processes. Using it would give you the Node APIs implemented on top of libuv, plus third-party APIs available via NPM. -myk _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
