Google's Chrome browser draws heavily on the WebKit browser engine project led chiefly by Apple, but now WebKit is adopting one Chrome idea: separation between some computing processes.
Process separation in general can increase memory requirements, but it offers major advantages: a problem in one area doesn't necessarily crash the whole program, and it's easier to spread work across multiple cores of modern processors.
WebKit2 is an interface designed to be "non-blocking," according to a WebKit2 summary description. You can translate that as meaning it's designed for parallel programming challenges, where the execution of one computing process doesn't block another waiting for the first to release its claim on some resource.
Taking advantage of multiple cores is a major challenge facing the computing industry today now that simply increasing chip clock frequencies was halted by overheating problems. There's no indication about when it'll arrive for mainstream users of Safari, but this sort of significant internal change is generally of the type that would merit a new major version number.
Apple's WebKit2 move caused some indigestion for those it took by surprise.
"Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community?" asked Adam Treat in a follow-up message. Other browser "ports" also are based on the open-source WebKit software, including the KDE project's Konqueror browser from which WebKit itself stemmed, so others' projects could be affected by Apple's move.
"The time for that discussion is now. The forum is here," responded Apple's Darin Adler. But after Treat protested that the discussion was taking place after Apple announced it's about to start adding the WebKit2 updates, Apple's Maciej Stachowiak took a more conciliatory tone.
"We picked the name 'WebKit2' in the hopes of picking something really bland. Apparently that backfired, because it seems to make this project seem like a bigger deal than it is. Basically, you can think of this as a new port-specific API [application programming interface]. But we're trying to put some general mechanisms in this API, so other ports can use it if they choose. We are also welcoming input from the whole WebKit community on the design, architecture and direction of this work. It is at a very early stage, barely enough that you can build a trivial demo browser on top of it. We decided that our proof of concept was far enough along at that point that we should make the code public for community review and input.
"Nothing about the way existing ports work will go away, either immediately or in the foreseeable future. There will not even be any extra maintenance burden for anyone. WebCore will remain much as it is, there is imply a new WebKit layer on top now available. In fact, Apple's port for Mac OS X will continue to be maintained and will still be available as a system API."
Multiprocess designs are spreading throughout the browser industry. Firefox is splitting processes up through a project called Electrolysis, and one element of that called out-of-process plug-ins (OOPP) is growing nearer. Moving plug-ins such as Adobe Systems' Flash Player to a separate process can reduce the severity of crashes by isolating the problem.
The Firefox 3.6.4 (code-named Lorentz) is now available in beta form, Firefox release manager Christian Legnitto announced in a mailing list posting.,
"This beta offers uninterrupted browsing for Windows and Linux users when a problem causes a crash in any Adobe Flash, Apple Quicktime or Microsoft Silverlight plug-in instance. If a plug-in crashes or freezes when using Firefox Lorentz, it will not affect the rest of Firefox," Legnitto said.
Work to support the feature on Mac OS X also is under way, but that will be for a later version of Firefox.
Mozilla said earlier in the week it hopes to release Firefox 3.6.4 on May 4.
Via Dion Almaer.