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.
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. 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. Regards, Maciej 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
