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

[Maciej Stachowiak]

On May 16, 2011, at 10:08 AM, Adam Barth wrote:

> 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.

That solves the spec problem, but this doesn't automatically solve the code-level 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.

Another issue is that it's not obvious these features are getting in the way. In my own work in WebCore, I've never had to worry about the indexedb or audio api stuff, except for when I want to change things related to WTF classes, or in the way they affect my link time. It seems like, under the static library plan, that would continue to be true. IndexedDB does somewhat clutter the storage directory, since it is piled in there with all other storage APIs, but just putting it in a separate directory under WebCore would get it out of the way. Maybe others have different experiences.

The things that do get in the way a lot are optional features that are really intrusive in core code, like WML.

Regards,
Maciej