[webkit-dev] Thoughts on reducing the complexity of WebCore

[Adam Barth]

On Mon, May 16, 2011 at 2:59 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> The bindings layer isn't really on top of the Core. In particular, almost every API, however tangential, has an addition to the global Window namespace, and the "Core" part needs to be able to instantiate the right kind of Window object.

The specs for these features use the Supplemental attribute in WebIDL
to solve problem.

> Also, APIs that start standalone sometimes eventually grow to the point of dealing with DOM nodes of various kinds. For example, Audio will likely sooner or later interact with HTMLAudioElement. P2P may well end up having some involvement with HTMLVideoElement. Many features will also likely have interaction with the loader and the network stack.

Yeah, for a while I had a dependency from the standalone APIs to Core
(e.g., in the ASCII diagram in the P2P thread), but looking through
the code that seemed like good candidates for this model, I didn't
actually seem that many dependencies.  Of course, that doesn't mean
they won't be added in the future.

The loader is certainly a complex area here, but, from my point of
view, that points to improvements we should make in the loader.

> In addition, actually compiling as separate static libraries makes the build of WebCore more complicated, and likely slower (ar is slow on some platforms and does no incremental linking, so it's pure waste).
>
> For these reasons, I'm not sure making these things into separate static libraries is practical or helpful. I think isolating them to their own subdirectories is about the best we can do.

Ok.  Thanks for taking the time to provide feedback.

Adam


> On May 15, 2011, at 11:06 PM, Adam Barth wrote:
>> One way to reduce the complexity of WebCore without reducing the
>> number of features in WebKit is to separate out the parts of WebCore
>> that aren't tightly coupled to DOM/CSS/Rendering into separate
>> (static) libraries.  Consider, for example, IndexdedDB and WebAudio.
>> These APIs are part of the web platform (or at least aspire to be part
>> of the platform) but do not require tight coupling with many of the
>> other concepts in WebCore.  They're essentially JavaScript bindings
>> for platform functionality (storage and audio drivers).  As a
>> non-example, flexbox would not be a good candidate to factor out of
>> WebCore because flexbox tightly couples with CSS and layout.
>>
>> Here's one possible dependency diagram for how these pieces might
>> relate.  The blue boxes represent separate libraries (either static or
>> dynamic), and the arrows represent dependencies.
>>
>> https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?hl=en&authkey=CP6plYAI
>>
>> The "Core" library contains most of what's now in WebCore.  (We can
>> come up with a better name than Core, of course.)  The libraries to
>> the left of the diagram (a few examples are shown) contain code that
>> is today part of WebCore but that only needs to depend on Platform
>> (e.g., not on DOM or Rendering).  The Bindings layer is depicted near
>> the top of the diagram because most concepts in WebCore have
>> JavaScript bindings.  Ideally, the bindings layer would be as thin as
>> possible and as automatically generated as possible.
>>
>> Although I've drawn the dependency arrows pointing downwards, there
>> are some "upcalls" in this approach.  For example, Core upcalls to
>> WebKit via Client interfaces and upcalls to Bindings via the Script
>> objects.
>>
>> Moving some features into separate libraries might be an improvement
>> over the ENABLE macros we use today because folks who are uninterested
>> in the features can ignore the libraries entirely (e.g., not compile
>> them or not even open them in an IDE).  Unlike ENABLE macros, which
>> can easily spider throughout the codebase, libraries are naturally
>> more self-contained.
>>
>> I'm not suggesting that we move to this approach overnight, but I'm
>> interested in your thoughts as to whether this might be a model we
>> should consider as WebCore continues to grow in complexity.
>>
>> Thanks,
>> Adam
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>