[webkit-dev] Announcing WebKit2

Fri Apr 9 03:36:43 PDT 2010

On Fri, Apr 9, 2010 at 11:24 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

It was _very_ helpful.  Thanks for taking the time to explain it so well.
 (It might be worth moving some of that description and diagrams into the
Wiki as well.)

Anyhow, I sincerely do hope that we (Chromium + Apple) can both make it a
goal to share as much code as possible between our two implementations,
especially in WebCore.  Maybe it'd even be useful and practical to upstream
some Chromium code to WebKit to help further the "WebKit2" API (and share
more code)?  It'll be great to talk about this stuff at the meeting next
week.

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