[webkit-dev] WebKit modularization

Adam Barth abarth at webkit.org
Wed Feb 22 22:38:00 PST 2012


Here are a couple example of a patches that are part of this project:

https://bugs.webkit.org/attachment.cgi?id=128395&action=review
https://bugs.webkit.org/attachment.cgi?id=128247&action=review

Notice that we've removed a bunch of feature-spec code from "core"
classes like DOMWindow and Page.  The code we're removing doesn't
really have anything to do with the primary work done by DOMWindow or
Page.  The code just uses DOMWindow or Page as a context object.

The net result (hopefully!) is that the core classes should have less
code and many fewer ifdefs.

Adam


On Wed, Feb 22, 2012 at 10:08 PM, Kentaro Hara <haraken at chromium.org> wrote:
> 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


More information about the webkit-dev mailing list