Bug 79327

Summary: [meta] Modularize WebKit
Product: WebKit Reporter: Kentaro Hara <haraken>
Component: WebCore Misc.Assignee: Kentaro Hara <haraken>
Status: NEW ---    
Severity: Normal CC: abarth, ap, darin, dennisn, donggwan.kim, gyuyoung.kim, mario, michelangelo, mihnea, syoichi, webmaster
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 82266, 82276, 72138, 76723, 78440, 78467, 78860, 79259, 79293, 79343, 79377, 79379, 79432, 79434, 79436, 79437, 79442, 79449, 79473, 79479, 79507, 79517, 79598, 79619, 79624, 79625, 79626, 79633, 79635, 79636, 79663, 79721, 79881, 80013, 80061, 80071, 80094, 80139, 80140, 80144, 80148, 80151, 80178, 80193, 80248, 80325, 80352, 80393, 82121, 90580, 90940, 91324    
Bug Blocks:    

Description Kentaro Hara 2012-02-22 21:48:16 PST
We are planning to modularize WebKit. We are planning to split "self-contained" features out of WebCore/ into WebCore/Modules/. For example, we can move WebAudio, WebSocket, IndexedDB, ...etc from WebCore/ to WebCore/Modules/ as self-contained features.

The idea is that modules roughly correspond to features/specifications that aren't core to the rendering engine (like a CSS feature might be). Usually a module will be introduced with a corresponding ENABLE flag. Modules do not depend on each other. The dependency rule ensures that nothing outside the module will be burdened with knowledge/complexity of the ENABLE flag.

Modules enable us to develop self-contained features without touching WebCore/ code. We hope this will make it easier to develop features in each vendor.

Our WebKit modularization plan is here: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0

The WebKit modularization is realized by the [Supplemental] IDL attribute. You can find more information of [Supplemental] here: https://trac.webkit.org/wiki/WebKitIDL#Supplemental
Comment 1 Kentaro Hara 2012-02-23 21:02:56 PST
If you would work on WebKit modularization,

- please block this meta bug to track them
- please add the bug # to the SpreadSheet (https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0). Ask me if you need a write permission of the SpreadSheet.
Comment 2 Kentaro Hara 2012-02-24 15:32:18 PST
As pointed out in bug 79507, when we make supplemental DOMWindow*.idl, WorkerContext*.idl, Navigator*.idl etc, we should copy & paste the CopyRight of the original DOMWindow.idl, WorkerContext.idl, Navigator.idl etc.
Comment 4 Dennis Nezic 2021-10-05 11:35:15 PDT
This is sorely needed!! Especially with the javascript components. That seems to be what takes up the vast majority of compilation. It takes over a day to compile here, far more than any other package I've ever installed. This is the obvious common-sense thing to do, the linux / open-source thing to do, to separate the core components that rarely change, and other ones that often require updating, as separate packages. All the vulnerabilities seem to arise in the javascript code. We shouldn't be recompiling basic stable ossified stuff every month when a new major javascript vulnerability is found.

Compiling them as separate packages/libraries will also encourage more people to hack and contribute to the code base. Currently it's much too daunting, in terms of memory and cpu and disk usage, for most people. Even source-based distros like Gentoo are pressured to create ugly binary packages to deal with this.

As a tangent, why does the javascript stuff take so many hours/days to compile? It takes way longer than compiling the linux kernel and gcc and the whole gcc toolchain and a window manager combined!