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

[Maciej Stachowiak]

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.

Hi Adam,

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?

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. 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
intents
mediastream
vibration
websockets

== Possibly Planned Modules, Based on Previous Emails and the Spreadsheet ==

fileapi
filesystem
notifications
microdata
pagevisibility
pointerlock
protocolhandler
storage
webaudio
workers

== Current Non-Modules Using Module-Related Techniques for Loose Coupling ==

devicemotion
deviceoritentation
fileapi
html
notifications
protocolhandler
speechinput
svg
webgl
websql
workers
xml

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

events