Anders Carlsson, an Apple employee, announced today on the WebKit mailing list an evolution of the WebKit project called WebKit2.WebKit2's major aims are to bake both a "split process model" and a non-blocking API into the WebKit product—and by extension into Safari and any other client which takes advantage of the WebKit2 framework.
Google's Chrome browser launched in late 2008 with what's called a split process model, one in which each WebKit view runs in its own process. This means that when a bad plugin or a bug in the renderer causes an error, only that tab will crash instead of the entire browser.
IE8 has a similar system and Firefox is exploring one as well with Electrolysis. Apple's Safari 4 gained a related feature under Mac OS 10.6, which runs plugins like Adobe's Flash in a separate process and prevents the whole browser from crashing due to plugin faults. WebKit2 validates that approach by building support for split processes directly into the rendering engine.
Out of my way!
Another goal of WebKit2 is to implement the API to the framework in a completely non-blocking manner. This means that developers can hook into API methods with various kinds of callbacks in order to receive notifications from WebKit views.
For example, in my application I might want to load a webpage. I would call the loadWebsite method (which I just made up), pass it my URL, and additionally specify a callback method or block of code I would like to have attached to a particular event—say didFinishLoadForFrame (which I did not make up).
Whenever the webpage is done rendering, my code would be executed or my method called or pinged. This should result in much more responsive applications which hook into WebKit2. Theoretically, while the renderer is rendering something, the main application loop can move on to doing something else as requested by a user.
There are three techniques currently implemented to achieve this goal: notification-style client callbacks, policy-style client callbacks, and policy settings. A fourth method, code injection which can interact directly with the DOM, is proposed but not yet implemented. These are described in more detail on the project page.
The neat thing about Apple's implementation is that these abilities can be used and exploited by all downstream clients of WebKit2, since they are baked right into the framework—in contrast to the tack taken in Google Chrome. The end user of an application that uses WebKit2 will get a more stable product and developers can take advantage of these enhancements without having to implement their own solutions or jump through unnecessary hoops.
WebKit2 is currently supported on Windows and OS X—the two platforms on which Apple deploys Safari. Linux support is not mentioned at this time.
Source: Arstechnica.com
