[webkit-dev] Announcing WebKit2

[Dmitry Titov]

I'm curious if there is there an intention to include a sandbox
implementation in the WebProcess? In Chromium case, the process that hosts
WebCore pulls all the resources via IPC from the single browser process,
which has access to the actual network layer, cache etc. Will there be a
WebCore/platform/WebKit2?

Dmitry

On Fri, Apr 9, 2010 at 3:38 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Apr 9, 2010, at 9:09 AM, Darin Fisher wrote:
>
>
>> 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.
>
>
> Would this picture be more accurate?
>
>
>
>
> 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.
>
>
> I'm sure it's possible in principle, but I think there are a few
> challenges:
>
> 1) It's pretty hard to tell where exactly the boundary lies between
> straight-up app code and the multiprocess embedding layer, for someone who
> is not an expert in the Chromium code base.
> 2) The Chromium project didn't seem particularly interested in turning that
> layer into a true API with binary compatibility guarantees.
> 4) It didn't seem practical for a third party to make it a true API without
> essentially forking Chromium, which did not seem like a friendly move.
> 3) The Chromium project *does* want to have a binary compatible API
> boundary between the multiprocess embedding layer and WebKit itself, but an
> API that results in many key facilities being plugged in from outside of
> WebKit. That seems counter-productive towards the goal of making the
> multiprocess embedding layer itself be an API to WebKit.
>
> No offense is intended here, we simply have different goals and priorities.
>
>
> 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.
>
>
> It does seem possible to use it as the basis for a Web platform
> implementation in general, but it seems pretty hard to use it as the basis
> for a multiprocess embedding layer other than the one that's part of
> Chromium. Or at least, I am not aware of anyone seriously attempting such
> use.
>
>
> 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).
>
>
> Yes, I think that's the key difference in approach. That's what I was
> trying to get across.
>
> 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/3f678728/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 68071 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/3f678728/attachment-0002.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/3f678728/attachment-0003.png>