[webkit-dev] Announcing WebKit2

[Alfonso Guerra]

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
<http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev>> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100411/a5bce356/attachment.html>