This is how we are designing the Pepper API [1] by the way. It is designed to be layered in order to support an optional, out-of-process implementation.
I've always been interested in a similar model for WebKit. -Darin [1] https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI On Fri, Apr 9, 2010 at 8:13 AM, Adam Barth <[email protected]> wrote: > The OpenGL approach to this problem is to have two layers with the > same API. (Sorry my diagrams aren't as awesome as Maciej's.) > > Application > --- WebKit2 API --- > Multiproc client implementation > === Process Boundary === > Multiproc server implementation > --- WebKit2 API --- > Singleproc implementation > WebCore, etc > > Notice that the WebKit2 API appears twice in this diagram. By > layering WebKit2 over itself, you allow for easy single-process > embeddings: > > Application > --- WebKit2 API --- > Singleproc implementation > WebCore, etc > > This design as worked well for OpenGL over a long period of time, > including several revolutions in underlying technology (system of > components, daughter board GPUs, integrated with the CPUs). > > Another benefit of this design is it separates the multiprocessing > concerns from the concerns of implementing the API because the > multiproc layer is purely concerned with proxying the API over a > process boundary. > > Adam > > > On Fri, Apr 9, 2010 at 8:00 AM, Evan Martin <[email protected]> wrote: > > On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson <[email protected]> > wrote: > >> WebKit2 is designed from the ground up to support a split process model, > >> where the web content (JavaScript, HTML, layout, etc) lives in a > separate > >> process. This model is similar to what Google Chrome offers, with the > major > >> difference being that we have built the process split model directly > into > >> the framework, allowing other clients to use it. > > > > One thing I'd discussed with the WebKitGtk folks in the past is > > whether/where multi-process WebKit fits into apps. An app that just > > wants a quick HTML component -- say it wants to embed some known > > safe/simple HTML content (consider for example the bits of the MS > > Windows control panel UI that are done in HTML, or the system help > > viewer) doesn't worry a lot about the stability/performance benefits > > of multiproc but might care about the memory/developer overhead. > > (Developer overhead for the embedder, in the sense that multiproc is > > more painful to debug and code for.) > > > > >From the original announcement I could see the above description going > > one of two ways: > > - WebKit2 could *support* a split process model, by adding all the > > callback-like hooks described, while still allowing an embedder to > > implement it in a single-process way > > - or WebKit2 could define and implement a split process model > > > > The Chromium port vaguely aims at the former, though I think it falls > > out more from not wanting to stuff even more Chromium-specific code in > > the WebKit tree. :) It seems from the graphics Maciej posted that > > the latter is what you're doing. Is that correct? Do you have any > > intent to continue supporting a single process model? > > > > (There's some compromise path between the above two, where you require > > the asynchronous interface but allow embedders to just use in a > > thread. We've found this to be a bit finicky to keep working in > > Chrome, and while that could be our bad engineering practices, if it's > > kept on the table it certainly will require continuing engineering > > effort to support.) > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
