On Sat, Nov 12, 2016 at 1:46 AM, <m...@melez.com> wrote: > 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 understand that. What I'd like to avoid is to be forced to embed Servo via an API that has been designed to be compatible with 3 engines. I imagine that a generic API has to be pretty abstract, limiting experiments and flexibility. Such a generic API could be built on top of a lower level API though. I also hope that we would be able to rebuild the CEF port on top of the Servo embedding API. > I'm curious to understand more about the WebKit/Gecko limitations you're > trying to avoid. I don't know much about embedding Gecko. As for webkit, I really like the way the browser capabilities are exposed on Android. You'll find that the API I drafted look a bit the same. But: 1) we want to have the freedom to tweak, improve and experiment with new ideas easily without worrying about compatibility. Like, the way JS interfaces are exposed (we want to use this https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule), finer control over the history and document state (cancelling pending pipelines, creating prerendering pipelines, controlling frozen state, rewrite history, …), delegating IO and session management, delegate session restore (see the LoadData struct we use all over the draft API)… If we start forking the API, then at the end, I believe there's no point of having a compatible API. Also, the same as for CEF, I hope we could easily re-implement such a generic API based on a lower-level Servo API. 2) we really want to have a better control over the compositor and viewport geometry. There are multiple behaviours we found impossible to implement today. For example: configure overscroll behaviour at anytime and for any frame edge (it's possible in webkit, but not from the embedder realm), dissociating clipping area and content area (see browserview.rs for use cases), animate - in a performant way - the way content is clipped (driven by a timing functions or by native events), be able to transform/composite the viewports easily, rendering "frozen pipelines" (documents from the history)… >> - 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? Primarily iframe mozbrowser. Both in Gecko (see the isapp/isbrowser code in docshell) and Servo (see the iframe & constellation code). But also some security policy (see the XHR Cors code in Gecko). Having multiple code paths DOM events, security behaviours, browsing context logic, etc - is messy. There's also the security model in Electron that used to be wonky (the node_integration + webview mess, and sandboxing). But things are being fixed. >> - 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. Yes. There are multiple designs we have been trying to put together but found just impossible to build in a performant way. A little bit of control over the compositor and events is necessary. > Seems reasonable, although I wonder if there's an abstraction for the common > cases of rendering some content in a rectangle. For the compositor part, I don't think the common case might be too difficult to implement. For events routing, we could imagine have a default event handler, and allow the embedder to override it. >> 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. I'll let Till answer this. I don't know much about what we want for the runtime. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
