[webkit-dev] WebKit modularization
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
> 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:
>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.
More information about the webkit-dev