On Mon, May 16, 2011 at 2:59 AM, Maciej Stachowiak <[email protected]> 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 >> [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
