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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
