On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson <ander...@apple.com> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
