|Kentaro Hara||Feb 22, 2012 10:08 pm|
|Adam Barth||Feb 22, 2012 10:38 pm|
|Ashod Nakashian||Feb 23, 2012 12:17 am|
|Adam Barth||Feb 23, 2012 12:29 am|
|Ashod Nakashian||Feb 23, 2012 2:48 am|
|Simon Fraser||Feb 23, 2012 10:07 am|
|Adam Barth||Feb 23, 2012 10:24 am|
|Simon Fraser||Feb 23, 2012 10:36 am|
|Pavel Feldman||Feb 23, 2012 10:54 am|
|Martin Robinson||Feb 23, 2012 11:16 am|
|Adam Barth||Feb 23, 2012 11:28 am|
|Alexey Proskuryakov||Feb 24, 2012 9:56 am|
|Adam Barth||Feb 24, 2012 10:00 am|
|Alexey Proskuryakov||Feb 27, 2012 11:45 am|
|Adam Barth||Feb 27, 2012 11:48 am|
|Adam Barth||Feb 27, 2012 11:54 am|
|Alexey Proskuryakov||Feb 27, 2012 12:42 pm|
|Adam Barth||Feb 27, 2012 1:47 pm|
|Subject:||[webkit-dev] WebKit modularization|
|From:||Kentaro Hara (hara...@chromium.org)|
|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: https://bugs.webkit.org/show_bug.cgi?id=79327
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
The WebKit modularization plan is here: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0
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!
-- Kentaro Hara, Tokyo, Japan (http://haraken.info)
_______________________________________________ webkit-dev mailing list webk...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev