[webkit-dev] WebKit modularization

Pavel Feldman pfeldman at chromium.org
Thu Feb 23 10:54:34 PST 2012


On Thu, Feb 23, 2012 at 10:24 PM, Adam Barth <abarth at webkit.org> wrote:

> On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser <simon.fraser at apple.com>
> 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):
>
>
It means that we'll need to put inspector agents (FileSystem, IndexedDB,
AppCache, etc.) into corresponding modules. As of today, they are
instantiated by the InspectorController. We will also need to split
InspectorInstrumentation into parts. This is all doable, but is an effort.
Were you planning to do it on your own? Please keep inspector folks in the
loop.


>
> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120223/b97f5e87/attachment.html>


More information about the webkit-dev mailing list