[webkit-dev] WebKit modularization

[Adam Barth]

On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser <simon.fraser at apple.com> wrote:
> On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote:
>> TL;DR: We are starting WebKit modularization. Self-contained features
>> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved
>> from WebCore/ to WebCore/Modules/.
>
> What are the interfaces that a module uses to call into WebCore code, and
> vice versa?

Currently, the plan is that there won't be any direct dependencies
from WebCore into code in Modules, but code in Modules will be able to
depend on anything in WebCore it likes.  We've added a couple abstract
"Observer" interfaces that Modules use to learn about what's happening
in WebCore.  So far, these have been very basic lifetime-related
observations (e.g., a Page and/or a Frame being
destroyed/disconnected):

http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h

The goal is to avoid adding much to these interfaces so that folks can
work on WebCore proper without worrying too much about these
"ancillary" features.

This diagram describes the dependency relationships:

https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI

> Will these be developed in an ad hoc manner, or is the intent
> to create some kind of generic extensibility API that modules use to
> hook into WebCore?

Ad-hoc.  At least in the near-to-intermediate term, all this code is
going to continue to live in Source/WebCore, so we're not creating any
new API commitments.  In the long term, we might benefit from moving
some of it out of WebCore entirely, but that's not something we're
planning to tackle any time soon.

Adam