[webkit-dev] Announcing WebKit2

[Maciej Stachowiak]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/2e65b416/attachment-0001.html>
-------------- 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/2e65b416/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: webkit-chromium-stack-v2.png
Type: image/png
Size: 68071 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/2e65b416/attachment-0003.png>