It almost got lost in all the iPhone OS 4.0 stuff, but Apple made a major contribution to the WebKit project yesterday. It’s called WebKit 2, and it adds multiprocess browsing to the WebKit API; it may look similar to what Chromium does, but the difference is that Chromium’s process boundary is not actually part of WebKit.
Apple’s Anders Carlsson made the announcement yesterday on the WebKit mailing list. “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,” Carlsson writes, “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.”
In WebKit-regular, there is no process boundary since the application and renderer sit in one process; there is, however, an API boundary that lies between the application and the WebKit API. In Google’s Chrome/Chromium, the process boundary lies above the API boundary, which makes it hard for other WebKit implementations to make use of it.
“Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself,” the WebKit 2 wiki page explains, “The Chrome team at Google did a great job at trailblaizing multiprocess browsing with Chrome. But it’s difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.”
In WebKit 2, the process boundary lies below the API boundary, which effectively makes multiprocess browsing a core part of the WebKit API. This also explains why it’s called WebKit 2: it’s incompatible with previous implementations.
“We want process management to be part of what is provided by WebKit itself, so that it is easy for any application to use,” the wiki page further explains, “We would like chat clients, mail clients, twitter clients, and all the creative applications that people build with WebKit to be able to take advantage of this technology. We believe this is fundamentally part of what a web content engine should provide.”
This is a great and very welcome contribution from Apple, and should definitely help in spreading the joys of multiprocess browsing across platforms and browsers. It also means that Opera and Firefox are now starting to look even more archaic compared to WebKit-based browsers and Internet Explorer (yes, IE8 implements multiprocess browsing). Get with the program, guys.
Here’s to Apple! A company that screws ISVs (blocking non native engines) and releases an awesome, open framework all at the same day.
Thom’s analogy about Hitler inventing the cure to cancer at a previous story comes to mind.
Before that gets taken out of context: as I made clear, that was a joke. I wasn’t serious.
Even if it was a joke it doesn’t remove the aftertaste of truth…
Edited 2010-04-09 17:13 UTC
I dunno, why microsoft tried to do this, they was taken to court and lost for law breaking. I have a feeling that Hitler .. I mean Apple will end up in court as well..
As for your comment, whether it was said jokingly or not, Apple really does act a lot like Hitler and should be called on it.
Some namby pamby is bound to get upset at the slightest sniff of anything related to the holocaust. Add cancer to the mix and you’re literally painting a target on your forehead
Although, it simplifies our thought processes to think of a company as always “good” or “evil”, it helps to keep in mind that we live in a much more subtle world than that.
Edited 2010-04-09 17:24 UTC
Of course. My post was highlighting just that.Â
But I think that even qualifying a company’s decisions as subtleties is shying away from the truth. The truth is that every company bases its decisions on profit. If you look at both decisions, the “good” and the “evil”, they both make perfect sense for Apple. Nothing subtle here. Why anyone should expect them not to take them is beyond me. Â
Exactly. There’s plenty of good reasons (like this) why people like the stuff Apple is doing, but there’s plenty of stuff they also do that is seriously problematic – see their barring usage of non approved languages f.e. (which doesn’t even make sense given their framework teams’ previous openness to alternative language interfaces like Ruby and Python much less OpenGL).
I seriously think I am not alone in being a fan of alot that Apple does, yet looking forward to them dealing with anti-trust/monopoly regimes which would ban some of their practices – breaking up their AppStore ‘monopoly’ (and remove restrictions for developers) would pretty much short-circuit most of these types of moves. However they want to run their own store doesn’t really matter from that point.
I think people get enraptured by the idea that companies themselves are good or evil – Microsoft was not a unique demon, it pursued profits in a rational manner. Apple is not a commmunist collective, it is another corporation out for profit maximization, and para-monopolies/lock-ins are the best way to guarantee that – the feudal sheikhs with big Apple holdings are well aware of that. I really don’t see any reason why ‘handheld computing’ is any less a market segment than personal computers vs. mainframes, and even controlling ~ 50% of the market can distort consumer choices when they pull stuff like this to restrict coders ability to target multiple platforms economically/realistically.
Edited 2010-04-09 17:58 UTC
They aren’t a monopoly, even in america. Android is significant, and Symbian is huge.
If Apple haven’t used GPL-ed KDE’s KHTML engine as a base for webkit, and if they actually have written it from scratch, you can be sure that webkit would be closed source and Apple wouldn’t release anything today.
It’s the open source license forcing them to be open, not the goodness in their hearts.
Some portions of Os X are theoretically “open source” due to the fact they reused large chunks of FreeBSD code.
Actually, they have not opened anything that it weren’t already open.
Edited 2010-04-09 17:45 UTC
Of course, because Apple has never, ever released any open source code unless they started with something already covered by the GPL /rollseyes.
Like they ever written something from scratch and release it under GPL? You got to be kidding.
A little dim aren’t you?
They’ve released quite a bit of open source code, not covered by the GPL. Some of this code written themselves, not based on pre-existing material.
They were not required in any way to release this non_GPL’ed code, but they did. I do not claim it is “out of the goodness of their hearts” but really, it doesn’t need to be for people to make use of it.
I’m not actually sure, but didn’t they write Grand Central Dispatch from scratch and then release libdispatch under BSD? Maybe my sarcasm detector is just on the fritz.
KHTML isn’t licensed under the GPL but the LGPL. That means that you can link against KHTML from a non GPL compatible licensed program. That in turn means that Apple could have kept most of Webkit closed source.
Same deal with OSX. The BSD license doesn’t require the source of the modifications to be released.
As for your last statement I won’t even bother.
Well, they did not link to the khtml libraries, they changed them quite a bit -> they had to release it as LGPL.
KDE’s code only resides in WebCore which is only a part of WebKit. In fact initially WebKit was closed source.
Webkit was initially closed source until the KHTML developers pointed out to Apple that, unlike the BSD license, the LGPL license does NOT mean “take our work, close it up as proprieatry and profit from it”.
Which is a load of crap; the delay between providing contributions back had to do with the logistics of it, the fact that they were developing a browser in secret, and how the KHTML community would merge huge amounts of code coming from Apple into a hugely different code base than when it was originally forked. There was a schism between KHTML and Apple developers thus the webkit project was launched where Apple didn’t have to go to all the effort of hand wrapping the code specially for KHTML developers to merge into the main tree.
Apple at no time ever denied that that they used KHTML; oh, and regarding LGPL, you can link against the webkit library under the LGPL which is what Apple has done. Just a small surprise mate, you aren’t the perfect all knowing guru that you try to make yourself as.
Edited 2010-04-12 08:20 UTC
As far I understand they _had_ to modify it.
What you need to keep in mind is that only KHTML was under LGPL, not all the libaries KHTML itself used.
Sorry, but no.
The LGPL allows you to write proprietary code, statically link it with an (unchanged) LGPL library, and yet still release the resulting program as closed-source proprietary program.
That is not what Apple did with the KHTML code. Apple modified KHTML code itself (aka known as “forking the code”), and made webkit out of it, and then distributed webkit (as part of their Safari browser). Apple did not merely link in KHTML as a library.
That means that under the terms of the LGPL, Apple are still obliged to release their changes (i.e. the webkit fork of KHTML) as open source code, also licensed under the LGPL.
Perhaps Apple themselves didn’t realise this when they used KHTML, as they had previously been used to taking BSD code, changing it and giving nothing back. Perhaps this is why Apple took as long as they did to give back webkit as LGPL code.
LGPL is not the BSD license. LGPL is still copyleft for the LGPL code itself.
Edited 2010-04-10 11:29 UTC
You have no clue.
1.) KHTML is LGPL, not GPL.
2.) Apple developed many additions that aren’t even needed to be released as FOSS, because the LGPL allows those parts to be proprietary. Those parts are released under a BSD license.
BTW: Do you know who owns CUPS, the premier Unix/Linux printing framework? Apple. Apple does not need to release CUPS under GPL, but does so anyway.
Apple does not need to release its many LLVM contributions, but does so anyway.
Apple did not need to open source Launchd, Darwin CalDAV Server, Streaming Streaming Server, etc. under Apache License, but did so anyway.
No, keeping CUPS and similar technologies would have only led to CUPS being forked leaving APPLE-CUPS incompatible with all the other implementations, which is neither desirable nor financially wise for Apple.
In other words, it would take more of Apple´s money and time to maintain CUPS on its own than with the participation of all the other users that test it, build it and find bugs.
And Apple became the owner of CUPS through acquisition, they didn´t develop it in-house and then GPLed it. So stop trying to re-write history for those that don´t know any better.
Having said all of the above, it´s good when the goals of maximizing profit and keeping a project open to all participants are aligned, but let´s not mistake Apple´s opportunistic use of open source code for any kind of commitment to a more open platform, open web or open anything.
Edited 2010-04-10 17:07 UTC
I didn’t write that CUPS was not bought. So shut up and stop accusing me of “rewriting history”.
Other tools like the Streaming Server are fully developed in-house by Apple and have been open sourced by Apple alone.
CUPS was an existing piece of GPL software that Apple bought the copyright for, so the code is GPL no matter what Apple do.
As the copyright owners, they *could* change the license to something proprietary if they wanted – but only for future versions. Existing released code would still be available under the GPL, and Apple could not legally stop anyone else from adopting it and continuing CUPS development under a new name…
So no, Apple doesn’t have to release CUPS under GPL. But refusing to do so wouldn’t gain them anything, and would needlessly upset potential customers (not that that seems to stop them lately).
I don’t think you understand Apple very well. Apple has a very simple and powerful web strategy with webkit. Just because they don’t focus on the web, write for the web, etc… doesn’t mean they don’t get it.
Apple’s stance on Adobe right now has as much to do with the suffering Apple endured under IE from ’96 to ’06 (Apple freed itself of IE in ‘o3, but it’s only been the last few the entire web has started to shrug off IE, and there is still a long way to go).
And why do you think Apple would be so stupid as to care about something that doesn’t make any money but still be wielded as a powerful force.
Yea all those ISVs making money off the iPhone really seem screwed.
All this shows is that, as some of us have known and understood for a long time, Apple is neither good nor evil, they are a corporation, whose responsibility is to return as large a profit as possible to their shareholders. When people lose their own RDF about Apple – that they’re either inherently evil or can’t do anything wrong – and understand what is the truth, nearly everything they do makes perfect sense.
GNOME’s default web browser, Epiphany, has switched from Gecko to WebKit. (but I think most GNOME users use Firefox anyway)
Diversity of web browsers is great because it makes it harder for any company or group of companies to dictate how web pages should be written.
Diversity thus encourages standards, and standards let free software play on an equal footing.
(Off course, a GPL’d engine would be even better.)
Diversity is great, but as of today Firefox is still greater.
Wake me when WebKit can render XUL.
XUL is not a standard, nor even fully specified, and it’s most certainly not a w3c standard. Thus, why should WebKit render it?
The best thing that could happen to Firefox would be for XUL to be deprecated.
Uh, XUL is their platform.
The best thing that could happen to Firefox is for it to cease to exist?
XUL is the GUI, not the platform. And it’s XUL that makes a lot of the Mozilla apps feel slow. They replicate a lot of GTK+ in XUL.
Sure, XUL allows for a lot of neat customisations of the GUI. But it also adds a lot of bloat to the execution of the app.
Lose a bit of the customisation by dropping XUL and gaining a slimmer app and faster GUI. Sounds like a good trade to me.
I don’t know the details of the current implementation, but XUL really should be direct-on-Xlib (or XCB — we should be so lucky) and only use toolkit libs to do theming.
Firefox is far from better, you forgot the slow bloated part. Any of the browsers using WebKit runs circles around FF for over all speed / responsiveness and especially page rendering performance.
I’ll take good over fast any day. I suppose many would disagree.
I’m diggin’ Epiphany now. They are farther ahead with HTML5 Support than Firefox.
http://html5test.com/
Epiphany 2.30 Score: 138/160
Firefox [Iceweasel] 3.6.3 Score: 101/160
Throwing the Audio/Video wedge issue aside, Firefox is horrific on HTML5 Forms support, non-existent with section elements, grouping content elements and text-level semantics elements.
Interesting site that test link. It appears Safari doesn’t support MP3 or AAC for audio which I find rather strange as I would have expected it to just pickup support from QuickTime as it appears to have done in the case of Vorbis. Only scores 120 as well.
Pretty sure the test is bad as far as section and grouping elements are concerned… they might return “HTMLUnknownElement” rather than “HTMLElement” as the test expects, but layout-wise, they work fine.
I’ve built several sites using them, no problems, and they even work on IE8 with just minor hacks…
This sums it up:
http://trac.webkit.org/wiki/WebKit2
Specifically:
Apple Drops WebKit 2 Code, Adds Multiprocess Browsing
Hmmm. Because webkit is a fork of KHTML, and KHTML was LGPL code, that means that Apple are obliged to keep webkit as LGPL code.
Nokia have released webkit as a part of Qt.
http://trac.webkit.org/wiki/QtWebKit
That means that Nokia’s Meego will get this new Multiprocess Browsing (since Meego is based on Qt).
http://meego.com/
http://meego.com/community/blogs/imad/2010/day-1-here-opening-meego…
I wonder how Apple really feel about helping Nokia’s platform?
Edited 2010-04-10 11:40 UTC
The same as Nokia feels about helping Apple, because Nokia too has employees working full-time in upstream WebKit.
Sorry, Thom but that just sounds like they stopped developing it. Maybe you should use release word instead of drop when code is concerned. Since papers are dropped, a lot of things are dropped, but code and software is released.
Edited 2010-04-12 21:42 UTC