atom feed18 messages in org.webkit.lists.webkit-dev[webkit-dev] WebKit modularization
FromSent OnAttachments
Kentaro HaraFeb 22, 2012 10:08 pm 
Adam BarthFeb 22, 2012 10:38 pm 
Ashod NakashianFeb 23, 2012 12:17 am 
Adam BarthFeb 23, 2012 12:29 am 
Ashod NakashianFeb 23, 2012 2:48 am 
Simon FraserFeb 23, 2012 10:07 am 
Adam BarthFeb 23, 2012 10:24 am 
Simon FraserFeb 23, 2012 10:36 am 
Pavel FeldmanFeb 23, 2012 10:54 am 
Martin RobinsonFeb 23, 2012 11:16 am 
Adam BarthFeb 23, 2012 11:28 am 
Alexey ProskuryakovFeb 24, 2012 9:56 am 
Adam BarthFeb 24, 2012 10:00 am 
Alexey ProskuryakovFeb 27, 2012 11:45 am 
Adam BarthFeb 27, 2012 11:48 am 
Adam BarthFeb 27, 2012 11:54 am 
Alexey ProskuryakovFeb 27, 2012 12:42 pm 
Adam BarthFeb 27, 2012 1:47 pm 
Subject:[webkit-dev] WebKit modularization
From:Kentaro Hara (
Date:Feb 22, 2012 10:08:24 pm

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

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 or complexity of the ENABLE flag.

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

The meta bug is here:

The WebKit modularization is realized by the [Supplemental] IDL attribute. You can find more information of [Supplemental] here:

The WebKit modularization plan is here:

In the above SpreadSheet, there are two columns, "Temporary destination" and "Final destination". The "Final destination" indicates the directory to which we want to move the APIs eventually. That being said, sometimes the API move requires non-trivial changes or discussions with API maintainers. For example, moving all File APIs to WebCore/Modules/filesystem/ at a breath would be too complex and controversial. For such APIs, we are planning to first move the APIs to the "Temporary destination", (which would be trivial and harmless,) and then move the APIs to the "Final destination" based on the discussion with API maintainers.

If you have any concern, please let me know. Thanks!