We want to be able to embed Servo in applications. We want to build a functional Servo based browser. In Rust, in JavaScript, or any language.
The 2 ways to do so today is either to use CEF, a C++ embedding API (with multiple bindings) designed for Webkit/Blink, or use the mozbrowser API which requires the user to use HTML and JavaScript, and which tend to pollute the Servo code base and the web standards. I would like to start a discussion about a possible better embedding story, and also about getting rid of the mozbrowser code. 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) - it is Rust-first. Then bindings for JavaScript and any other popular language - it doesn't bend existing web standards and pollute the code base - 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 - give deeper access to the engine, especially to the compositor and events management I have outlined a proposal here: https://github.com/paulrouget/servo-embedding-api/ It's a draft. It's high level. It's not valid Rust code.The goal is to outline a future servo_traits API. The README includes some notes about the rational. There are a lot of comments inside the code itself. 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 The major short term changes necessary in Servo I foresee are: - move `fn main()` out of Servo (basically make Servo a library) - support multiple frame tree, support multiple compositors and WR instances - support multiple root frame in the constellation - support creation of a new compositor and a new browser at anytime - change the way web content is clipped (see browserview.rs) - delegate events routing to the embedder (there's probably a lot of things I haven't considered. please comment) The first milestone would be to rebuilt the current Glutin port but with `fn main()` within /ports/, without any reference to glutin within /components/, with multiple window support, and only relying on a servo_traits API. A second milestone would be to build a JavaScript binding, a bit like the Electron webview works, as a third-party project (no impact on the servo code base, only use the servo_traits API), and remove all the mozbrowser code from Servo, while keeping browserhtml functional. ~~~~~ Please take a look at https://github.com/paulrouget/servo-embedding-api We would need now: - to agree that we want a servo-specific rust embedding API - to agree on a minimal API that we could start working on, which I hope will be a subset of what I'm describing here: https://github.com/paulrouget/servo-embedding-api Then: - I will describe precisely the next milestones (glutin/miniservo port, then mozbrowser killing plan) - I will file relevant bugs. The same way I did for the initial BrowserHTML developer preview Thanks, -- Paul Rouget _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
