[webkit-dev] Announcing WebKit2

Fri Apr 9 03:24:51 PDT 2010

On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:

> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat <treat at kde.org> wrote:
> On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
> > On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
> > > Can someone please point to the bug report and the forum where  
> this
> > > development was discussed by the greater WebKit community?
> >
> > The time for that discussion is now. The forum is here.
> >
> > I suggest we use this mailing list, not a bug report.
>
> Isn't that a little cart before the horse?  It is already actively  
> being
> landed...
>
> I'd have to agree.  A new port is a maintenance burden on the entire  
> community.  Normally we discuss such things before starting to  
> commit them.

Given what proportion of overall maintenance work on WebKit I done by  
Apple, I don't think anyone is entitled to veto us adding a new API  
layer. I also recall that when the Chromium API layer was added, no  
one asked permission, you just let us know that it was coming. Which  
is fine - API layers are pretty low cost, and I hope no one would  
argue against a major contributor including theirs. What's more, this  
is really a parallel version of existing well-maintained API layers. I  
do not like the implication that Apple should have to ask permission  
for what we do with the WebKit API on Mac OS X. We do not ask the Qt  
or Gtk developers to explain all their API choices.

> For example, my first question is whether we can adapt the Chromium  
> WebKit API (or devise an API that could replace the Chromium WebKit  
> API) since it sounds like our goals and the goals of this new API  
> are fairly similar.  If we do the former, I'm sure we can talk about  
> changing the name.  :-)

Actually, the goals are quite different. The Chromium WebKit API is  
designed to go underneath a process management and proxying layer that  
is provided by the embedding app. Chromium by design does not put any  
of the multiprocess logic in WebKit itself - it just adapts WebKit so  
that it can be used as a component of a multiprocess application.

The WebKit2 API provides that logic underneath the API boundary, so  
it's not necessary for every client application to implement it for  
themselves. This is critical for our use cases, because we anticipate  
having more than one client.

Here's some pictures to make the difference more clear. This is a  
block diagram for an app using the standard Mac WebKit:

Everything is in one process and there is an API boundary in the  
middle. Apps can all do their different things using the WebKit API,  
and the complexity of making basic use of the WebKit API is minimal.

Here is the Chromium model (ignoring the detail of multiple render  
processes):

The process boundary is in the middle of the application, and the API  
boundary sits below that. This model is really only suitable for a  
single client application. All the complex process management,  
proxying and sandboxing code live in Chromium application code, not in  
WebKit. If any other application wanted to use Chromium WebKit to  
build a multiprocess browser, they would have to either reinvent or  
cut & paste a great deal of code from Chromium. There's really not  
much in WebKit that help you with the multiprocess issues - all it  
does is proxy a bunch of things up to the application level, which  
then takes care of the multiprocess issues.

Here is how we are designing WebKit2:

Notice what's different - the process boundary is *below* the API  
boundary and sits in the middle of the WebKit layer. That means any  
application can get all the benefits of a separate process for Web  
content simply by using the WebKit API. There is no need for each  
application to reinvent or copy the tricky code for cross-process  
proxying.

Simply put, Chromium WebKit did not provide what we needed to build an  
API that handles multiprocess and can sanely be used by many  
applications. While we could have built the WebKit2 API on top of  
Chromium WebKit, that would just be an unnecessary level of  
indirection compared to building on WebCore, and would not help us  
solve the technical challenges involved.

It was a reasonable choice for Google to build multiprocess and  
sandboxing outside WebKit instead of inside, given that Chrome started  
as a secret project, and you have no other clients for your API. But  
it makes the Chromium multiprocess code fundamentally not reusable for  
other WebKit clients or other WebKit port. With WebKit2, we are  
looking to build reusable multiprocess.

We have discussed this difference in goals and architecture with  
members of the Chrome team at Google before our source release (since  
we did not want the Chrome team to be blindsided by this effort). We  
hope to find ways to collaborate, since it is likely a number of  
WebKit features will need a Web Process / UI Process split that can  
work in very similar ways between Chromium WebKit and WebKit2. We hope  
to learn from the experience of the Chrome team, and perhaps even use  
portions of Chromium code where appropriate.  And we hope over time we  
can unify even further.

I hope this post clarifies why the Chromium WebKit port is not really  
a viable solution for our needs as it stands today.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/b4736654/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mac WebKit Stack.png
Type: image/png
Size: 39473 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/b4736654/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chromium WebKit Stack.png
Type: image/png
Size: 63526 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/b4736654/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WebKit 2 Stack.png
Type: image/png
Size: 63290 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/b4736654/attachment-0005.png>