[webkit-dev] The Care and Feeding of WebCore Modules

[Maciej Stachowiak]

On Feb 28, 2012, at 11:25 AM, Darin Fisher wrote:

> On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 
> Having read the wiki page, I'm even more unhappy with the approach that has been taken than I used to be. In fact, it is harmful even to the goals of the refactoring.
> 
> If a single #ifdefed line in DOMWindow.idl is a burden for development, what about adding several new files to each and every build system, and maintaining these multiple files into perpetuity? That's much more work for everyone - port maintainers, core developers, and feature developers. The likelihood of repeated breakage is higher with the need to maintain a more complicated build system.
> 
> Sticking to the concrete example, these lines in WorkerContext.idl are not really something a WebSocket engineer maintains. It's more important for a person working on JS bindings and/or on threading, and the need to hunt down these across many files makes hacking more difficult. How can one even find an answer to the very practical question of which properties are available on WorkerContext if these are split across multiple files?
> 
> Is this something the build system could help address?  Perhaps a by-product of the build is or could be a single file that contains everything that will be exposed on WorkerContext / DOMWindow?
> 
> I know studying a generated file is never as nice as studying a source file, but perhaps there is a compromise of this sort that could work?
> 
> I guess I'm just a big fan of modularization.  It seems helpful to separate logical units and minimize large "cross roads" files.

The counterpoint is that decorating objects purely from the outside can be a pattern that's hard to understand, when the "decorations" actually affect the behavior of the object being augmented. Sometimes, making the relationship explicit on the receiving end is easier to understand, even if it results in a "cross roads" file. I'm not really sure myself where the tradeoff lies, but I'm a bit wary of applying the pattern everywhere as much as possible.

>From the initial mail about modules, I got the (perhaps mistaken) impression that it would be used only for selected features that had very loose coupling and were perhaps not even of interest to every port. That seemed like a fine experiment to try, to see if it actually reduces the impact of these features.

But it seems like what is actually happening is wholesale rapid application of this pattern to all of WebCore, including even things that aren't in the Modules directory. So it's starting to seem more like a major restructuring of WebCore than like a lower-impact way of doing new peripheral features. It seems to me that starting on a more limited scale would have a better opportunity to measure WebKit community buy-in. If the main motivation for this project is hackability, then I think it needs to make people feel like hackability is actually improving. Ideally we'd measure that with an incremental step of some kind before applying it everywhere. 

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120228/1adaac18/attachment.html>