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

[Adam Barth]

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