atom feed29 messages in org.webkit.lists.webkit-devRe: [webkit-dev] The Care and Feeding...
FromSent OnAttachments
Adam BarthFeb 28, 2012 12:29 am 
Darin FisherFeb 28, 2012 7:40 am 
Adam BarthFeb 28, 2012 8:46 am 
Darin FisherFeb 28, 2012 10:27 am 
Simon FraserFeb 28, 2012 10:46 am 
Adam BarthFeb 28, 2012 10:50 am 
Alexey ProskuryakovFeb 28, 2012 11:11 am 
Darin FisherFeb 28, 2012 11:11 am 
Maciej StachowiakFeb 28, 2012 11:24 am 
Darin FisherFeb 28, 2012 11:25 am 
Maciej StachowiakFeb 28, 2012 11:52 am 
Alexey ProskuryakovFeb 28, 2012 11:53 am 
Adam BarthFeb 28, 2012 12:15 pm 
Adam BarthFeb 28, 2012 12:20 pm 
Adam BarthFeb 28, 2012 12:22 pm 
Adam BarthFeb 28, 2012 12:40 pm 
Maciej StachowiakFeb 28, 2012 1:59 pm 
Adam BarthFeb 28, 2012 3:47 pm 
Kentaro HaraFeb 28, 2012 4:43 pm 
Greg BillockFeb 28, 2012 5:19 pm 
Adam BarthFeb 28, 2012 5:21 pm 
Kentaro HaraFeb 28, 2012 5:46 pm 
Ryosuke NiwaFeb 28, 2012 5:58 pm 
Maciej StachowiakFeb 29, 2012 11:31 pm 
Adam BarthFeb 29, 2012 11:40 pm 
Kentaro HaraFeb 29, 2012 11:49 pm 
Adam BarthFeb 29, 2012 11:56 pm 
Kentaro HaraMar 1, 2012 12:05 am 
Alexey ProskuryakovMar 2, 2012 2:57 pm 
Subject:Re: [webkit-dev] The Care and Feeding of WebCore Modules
From:Maciej Stachowiak (
Date:Feb 28, 2012 11:52:03 am

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

On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov <> 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

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