On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser <[email protected]> wrote: > On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: >> TL;DR: We are starting WebKit modularization. Self-contained features >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >> from WebCore/ to WebCore/Modules/. > > What are the interfaces that a module uses to call into WebCore code, and > vice versa?
Currently, the plan is that there won't be any direct dependencies from WebCore into code in Modules, but code in Modules will be able to depend on anything in WebCore it likes. We've added a couple abstract "Observer" interfaces that Modules use to learn about what's happening in WebCore. So far, these have been very basic lifetime-related observations (e.g., a Page and/or a Frame being destroyed/disconnected): http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h The goal is to avoid adding much to these interfaces so that folks can work on WebCore proper without worrying too much about these "ancillary" features. This diagram describes the dependency relationships: https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI > Will these be developed in an ad hoc manner, or is the intent > to create some kind of generic extensibility API that modules use to > hook into WebCore? Ad-hoc. At least in the near-to-intermediate term, all this code is going to continue to live in Source/WebCore, so we're not creating any new API commitments. In the long term, we might benefit from moving some of it out of WebCore entirely, but that's not something we're planning to tackle any time soon. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
