[webkit-dev] WebKit modularization

[Ashod Nakashian]

Adam,

Sounds good. Consider me working on WorkerContext. I'll create a separate bug for moving file-api out of WorkerContext and create a patch for moving it to the temp. destination per the spreadsheet.

Regarding the build system, I couldn't agree more. I'd like to help in improving it. I have some tasks on the back-burner, but it's a bigger bite than I can muster the time for, at least for now. But I agree moving platform sounds like the one with the bigger impact.

I'm in Yerevan, Armenia UTC+4, btw.
-Ash



________________________________
 From: Adam Barth <abarth at webkit.org>
To: Ashod Nakashian <ashodnakashian at yahoo.com> 
Cc: Kentaro Hara <haraken at chromium.org>; WebKit Development <webkit-dev at lists.webkit.org> 
Sent: Thursday, February 23, 2012 12:29 PM
Subject: Re: [webkit-dev] WebKit modularization
 
On Thu, Feb 23, 2012 at 12:18 AM, Ashod Nakashian
<ashodnakashian at yahoo.com> 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/.
>
> Are there plans to split the project build files as well into separate
> sub-projects?

That's not something we're planning to do in the short term, but it's
a logical next step.  If the project had a sane build system, we'd
probably do that sooner rather than later.  :)

The bigger project in that regard is moving WebCore/platform into a
separate project called Platform.  That would significantly reduce the
number of files and lines of code in WebCore.  IMHO, that's more
valuable in the near term.

> 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?

Depending on your time zone, feel free to ping Kentaro or me on
#webkit.  An easy thing to do is to pick a block of lines from the
spreadsheet Kentaro linked to below, write a patch, and upload it to a
bug blocking <https://bugs.webkit.org/show_bug.cgi?id=79327>.

For example, you could write an analogous patch to
<https://bugs.webkit.org/attachment.cgi?id=128247&action=review> for
moving the ENABLE(FILE_SYSTEM) code out of WorkerContext.  That's
lines 485-492 on the spreadsheet.

Thanks!
Adam


> ________________________________
> 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
>
>
>
> _______________________________________________
> 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/1ba687c0/attachment.html>