[webkit-dev] WebKit modularization

[Adam Barth]

On Thu, Feb 23, 2012 at 10:36 AM, Simon Fraser <simon.fraser at apple.com> wrote:
> 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?

Yes, that's correct.  In some cases, "controller" objects (which today
are created by Page itself) are instead instantiated by the WebKit
layer when associating clients with the Page.  However, these objects
don't do much unless they're tickled via the bindings.

> Is module availability simply determined
> at build time via ENBALE flags?

To the build system, files in the Modules directory look just like
files in any other directory.  Nothing is changing in this regard.  (I
think that means the answer to your question is "yes".)

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

Yes, definitely.

On Thu, Feb 23, 2012 at 10:54 AM, Pavel Feldman <pfeldman at chromium.org> wrote:
> On Thu, Feb 23, 2012 at 10:24 PM, Adam Barth <abarth at webkit.org> 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):
>
> It means that we'll need to put inspector agents (FileSystem, IndexedDB,
> AppCache, etc.) into corresponding modules. As of today, they are
> instantiated by the InspectorController. We will also need to split
> InspectorInstrumentation into parts. This is all doable, but is an effort.
> Were you planning to do it on your own? Please keep inspector folks in the
> loop.

I haven't looked much at the inspector agents.  I wasn't planning to
worry about this in the near term.  If you think it would benefit the
inspector to change how this works today, we can certainly coordinate.
 If the current approach is working fine for you, I'd be inclined to
wait.

On Thu, Feb 23, 2012 at 11:16 AM, Martin Robinson <mrobinson at webkit.org> wrote:
> Is it too ugly to reach across layers and use these interfaces in
> WebKit? They might come in handy. I've already looked at one patch
> that uses FrameDestructionObserver in WebKit.

I don't have a strong opinion on this topic.  FrameDestructionObserver
is remarkably useful.

Adam