[webkit-dev] The Care and Feeding of WebCore Modules

[Adam Barth]

On Tue, Feb 28, 2012 at 1:59 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Feb 28, 2012, at 12:20 PM, Adam Barth wrote:
>> On Tue, Feb 28, 2012 at 11:52 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> But it seems like what is actually happening is wholesale rapid application
>>> of this pattern to all of WebCore, including even things that aren't in the
>>> Modules directory. So it's starting to seem more like a major restructuring
>>> of WebCore than like a lower-impact way of doing new peripheral features. It
>>> seems to me that starting on a more limited scale would have a better
>>> opportunity to measure WebKit community buy-in. If the main motivation for
>>> this project is hackability, then I think it needs to make people feel like
>>> hackability is actually improving. Ideally we'd measure that with an
>>> incremental step of some kind before applying it everywhere.
>>
>> I think this is a mischaracterization of the work we've been doing in
>> this area.  Are the particular patches you think would benefit from
>> more discussion?  You've mentioned the DOMWindowHTML patch, which we
>> can certainly revert and re-consider later.
>
> I'm sorry if you think I mischaracterized your work, and I see in retrospect that my wording was overly judgmental. Here's the point I was trying to get at. The discussion threads about the Module have been superficially about the mechanism, but I think at the root of these discussions are the following two and a half questions:
>
> 1) What should be a Module (now that we understand what that implies in addition to a directory move)?
>    1)a) In addition to what specific existing code should be a Module, what standards should we apply in the future?
> 2) To what extent should Module-like techniques be applied to non-Modules?

Those sound like good questions.  Our approach hasn't been to try to
answer all these questions upfront but rather to work on the low
hanging fruit, learn, and iterate.

> I think if we all have a shared understanding of the answers to these questions, it will greatly reduce the confusion/controversy around Module-related changes, and therefore make it easier for you and the others working on this project to get your work done
>
> Below is my understanding of the current state of the code and potential future plans, which anyone more knowledgable should feel free to correct.
>
> Once we have the right list to look at, I'm sure I and others will have comments about specifics. For example, I think File API (as opposed to Filesystem API more specifically) would be a poor candidate for a module since it is used by core code.

That's consistent with our current thinking (which is different from
our previous thinking, for exactly the reasons you state above).

> However, I'd like to make sure I'm looking at the right data before I comment, since I'm not sure modularizing File API is even part of the plan any more.
>
> == Existing Modules ==
>
> gamepad
> geolocation
> indexeddb

^^^ indexeddb is more of a work-in-progress than the rest of these.
We're still sorting out the relationship with SQLDatabase.

> intents
> mediastream
> vibration
> websockets
>
> == Possibly Planned Modules, Based on Previous Emails and the Spreadsheet ==
>
> fileapi

^^^ Currently, we're thinking this wouldn't be a good choice because
concepts like Blob are used throughout WebCore.

> filesystem
> notifications
> microdata

^^^ This one probably isn't a great choice either because it's
relatively tightly coupled to HTML (and is part of the HTML
specification itself).

> pagevisibility
> pointerlock

^^^ After discussing this feature in
<https://bugs.webkit.org/show_bug.cgi?id=79625>, we marked the bug
WONTFIX.  There some discussion in the bug about why.

> protocolhandler
> storage

^^^ There's a bunch of different features mixed together in this
directory.  IndexedDB and SQLDatabase look like good candidates for
becoming modules.  I haven't studied the rest of the code to have much
of an opinion on the rest.

> webaudio
> workers

^^^ I view workers more as a "hub" rather than a "spoke", much like
DOMWindow is a hub.  We don't have any plans to modularize workers.

> == Current Non-Modules Using Module-Related Techniques for Loose Coupling ==
>
> devicemotion
> deviceoritentation
> fileapi
> html
> notifications
> protocolhandler
> speechinput
> svg
> webgl
> websql
> workers
> xml

In some of these cases, such as notifications and websql, our hope is
to fully factor them out of WebCore proper.  We're taking an
incremental approach to loosen the coupling first and (if we succeed).

In other case, such as speechinput, we're using this same machinery to
loosen the coupling.  For example, we've removed a bunch of "junk"
code from Page:

http://trac.webkit.org/changeset/108446/trunk/Source/WebCore/page/Page.h
http://trac.webkit.org/changeset/108446/trunk/Source/WebCore/page/Page.cpp

> == Possibly Planned Future Uses of Module Techniques for non-Modules ==
>
> events

Similar to speechinput, there are a bunch of "controller" objects that
hang off of Page to share its lifetime but don't otherwise interact
with each other or with Page itself.  Using
<https://trac.webkit.org/wiki/Modules#Associatingstatewithcoreobjects>
we can remove this bloat/complexity/ifdefs.

Adam