[webkit-dev] WebKit modularization

[Ashod Nakashian]

Hi,

> TL;DR: We are starting WebKit modularization. Self-contained featureslike WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved
from WebCore/ to WebCore/Modules/.

Are there plans to split the project build files as well into separate sub-projects? 

Probably that's a separate undertaking, as it's not trivial. However I think it would be very beneficial to make each module independent with its own build scripts that produce library files. WebCore build could link all the modules into one final library, as is the case now, so nothing outside of WebCore changes as far as building the "upstream" projects are concerned. This approach would also minimize the feature-enabling infrastructure, as enabling modularized features would mean either they are built (and linked) or skipped. This would make the builds potentially faster and more manageable, allowing for module building and testing independently of WebCore and in faster iterations. Splitting the project build files should probably have its separate bug report with dependency on this one.

As an aside, I'd like to volunteer to work on the modularization bug. How can I coordinate my efforts and with whom?

-Ash

 

________________________________
 From: Kentaro Hara <haraken at chromium.org>
To: WebKit Development <webkit-dev at lists.webkit.org> 
Sent: Thursday, February 23, 2012 10:08 AM
Subject: [webkit-dev] WebKit modularization
 
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
webkit-dev at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120223/dd22aa5e/attachment.html>