On Feb 23, 2012, at 10:24 AM, Adam Barth wrote: > 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
>From this, it looks like the only way for a module to get instantiated at >runtime is via bindings. Is that correct? Is module availability simply determined at build time via ENBALE flags? > >> 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. I see. I just want to avoid the need for lots of intra-WebCore interfaces, as I'm sure you do too. Simon _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
