[webkit-dev] Announcing WebKit2

Fri Apr 9 09:18:23 PDT 2010

On Fri, Apr 9, 2010 at 5:09 PM, Darin Fisher <darin at chromium.org> wrote:

> On Fri, Apr 9, 2010 at 3: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.
>>
>
> I think you may be exaggerating a bit.  While it is true that a
> multiprocess embedding of WebKit exists in svn.chromium.org, it is not
> true that it is so coupled to Chrome the application so as to be unusable in
> other projects.  Despite how it may appear there are internal boundaries
> within Chromium.\
>

Note that some bits, like the (cross platform) IPC code is already quite
well isolated from the rest of Chromium into its own project.  It does have
dependencies on base (our equivalent to WTF which depends on stl but is
otherwise pretty light weight) + gyp...but the point is that it wouldn't be
_that_ hard to re-use existing, well tested components of Chromium for the
WebKit2 API.

> There are also alternatives to cut & paste or reinvention of the code from
> svn.chromium.org.  One could isolate the multiprocess embedding of WebKit.
>  It would mostly be a mechanical exercise.
>
> The Chromium WebKit API is a stable API to WebCore, but I grant you that it
> is not a complete embodiment of a web platform.  An application would need
> to supply some non-trivial pieces in order to use it as the basis for a web
> platform implementation.
>
> Finally, I think the architecture of WebKit2 is completely reasonable.
>  Afterall, it mirrors the design of Chromium quite closely (with the
> exception of course being where hard API boundaries have been defined).
>
> Regards,
> -Darin
>
>
>
>
>>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/046fbd0b/attachment-0001.html>
-------------- 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/046fbd0b/attachment-0003.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/046fbd0b/attachment-0004.png>
-------------- 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/046fbd0b/attachment-0005.png>