[webkit-dev] WebKit modularization

Simon Fraser simon.fraser at apple.com
Thu Feb 23 10:36:26 PST 2012


On Feb 23, 2012, at 10:24 AM, Adam Barth wrote:

> 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

>From this, it looks like the only way for a module to get instantiated at runtime
is via bindings. Is that correct? Is module availability simply determined
at build time via ENBALE flags?

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

I see. I just want to avoid the need for lots of intra-WebCore interfaces, as
I'm sure you do too.

Simon



More information about the webkit-dev mailing list