Pardon me for the late entry into this conversation, but as you'll be discussing this tomorrow in your meeting I wanted to add my perspective as a Mac developer for your consideration.

Since I'm new on the list, a little background info to help understand that perspective. Like thousands of developers out there, I have a notebook app. This app, named Mori, is being upgraded from letting users create content strictly as rich-text notes to holding PDFs, web archives, and various other document types. The document type UI and programmability is contained within plugins which I and third-party developers have created. When Chromium was announced, its feature of forking each web page into a separate process struck me as an intelligent way to deal with plugin security, and I anticipated adding such functionality to Mori in a future release.

Now with the arrival of WebKit2 Apple's advocating process management at an API level lower than content-handling, instead promoting a process API that while not invisible to the host app would seem to make it more difficult to cleanly manage processes for web-content types and non-web content. Or do I not fully understand the functionality provided by WebKit2 and WebCore (which I freely admit I do not)? Will I be able to fork and manage non-WebCore processes through this API? Will I be able to adjust process priorities to keep all processes of a certain MIME type (say application/x-shockwave-flash) to receive no more than 15% cpu time or monitor its memory usage? Do I need to subsume all my app's content-related functionality into WebKit to cleanly inherit the process model or else implement another Chromium-like process management layer on top for non-web content and still oversee the sub-API processes of WebKit2's scheme?

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


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

I would think there are more technical and performance challenges involved in the IPC in the middle of the stack rather than at the top, but I'm not yet acquainted with how you've factored out the processes.
> 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.

I believe Mori, and other rich-media (or multimedia or whatever we're calling it now) apps such as it, provide sufficient examples where that isn't to be the most likely case.
> I hope this post clarifies why the Chromium WebKit port is not really 
> a viable solution for our needs as it stands today.
Not really. As a host-app developer, I can't justify supporting 2 process models for content handlers in my app in this way. And excepting purely web-browsing apps, I don't see the benefit over the Chromium model to apps which provide users access to other types of content. As I said before, I'm not well-versed with WebKit's architecture nor the issues the WebKit2 team have been tackling that led them to see this path as the most practical manner in which to proceed. And WebKit has its clients, inside and outside of Apple, to answer to for which I'm owed neither an explanation nor alteration of the team's roadmap (or anyone else's from the community, for that matter).