Changes between Version 21 and Version 22 of Modules


Ignore:
Timestamp:
Feb 27, 2012 11:52:09 PM (9 years ago)
Author:
abarth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Modules

    v21 v22  
    55== Overview ==
    66
    7 As we add more features to WebCore, the project becomes more complex.  Some self-contained features, like IndexedDB and MediaStream, expose DOM interfaces but aren't otherwise involved in the core functionality of the engine, such as layout and rendering.  The module system let us reduce the complexity of the project by loosening the coupling of between these features and the rest of WebCore.
     7As we add more features to WebCore, the project becomes more complex.  Some self-contained features, like IndexedDB and MediaStream, expose JavaScript APIs but aren't otherwise involved in the core functionality of the engine, such as layout and rendering.  The module system let us reduce the complexity of the project by loosening the coupling of between these features and the rest of WebCore.  Often individual modules can be enabled with an `ENABLE` macro, but some modules are always enabled.
    88
    99== Dependency diagram ==
     
    1515== Associating JavaScript APIs with "core" objects ==
    1616
    17 Even self-contained features often need to expose JavaScript APIs on "catch-all" interfaces like DOMWindow or Navigator.  If we declared these APIs in DOMWindow.idl and implemented them in DOMWindow.h/cpp, the complexity of DOMWindow would increase with each added feature.  To avoid complexity creep in these core classes, you can declare your JavaScript API in supplemental IDL files, mirroring the "partial interface" WebIDL mechanism used in specifications.  For more details, see the [http://trac.webkit.org/wiki/WebKitIDL#Supplemental documentation of the Supplemental attribute].
     17Even self-contained features often need to expose JavaScript APIs on "catch-all" interfaces like `DOMWindow` or `Navigator`.  If we declared these APIs in [http://trac.webkit.org/browser/trunk/Source/WebCore/page/DOMWindow.idl DOMWindow.idl] and implemented them in [http://trac.webkit.org/browser/trunk/Source/WebCore/page/DOMWindow.cpp DOMWindow.cpp], the complexity of `DOMWindow` would increase with each added feature.  To avoid complexity creep in these core classes, you can declare your JavaScript API in supplemental IDL files, mirroring the "partial interface" WebIDL mechanism used in specifications.  For more details, see the [http://trac.webkit.org/wiki/WebKitIDL#Supplemental documentation of the Supplemental attribute].
    1818
    19 For example, the MediaStream module [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/NavigatorMediaStream.idl uses this mechanism] to add the webkitGetUserMedia API to Navigator.  The API is implemented in [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/NavigatorMediaStream.cpp NavigatorMediaStream.cpp], avoiding bloat in Navigator.cpp itself and helping to contain the MediaStream code in the MediaStream directory.
     19For example, the MediaStream module [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/NavigatorMediaStream.idl uses this mechanism] to add the `webkitGetUserMedia` API to `Navigator`.  The API is implemented in [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/NavigatorMediaStream.cpp NavigatorMediaStream.cpp], avoiding bloat in [http://trac.webkit.org/browser/trunk/Source/WebCore/page/Navigator.cpp Navigator.cpp] itself and helping to contain the MediaStream code in the MediaStream directory.
    2020
    2121== Associating state with "core" objects ==
    2222
    23 Sometimes a module needs to associate state with a core object, such as Page or Navigator.  Typically, this state doesn't interact with any of the other state associated with this object and simply piggybacks on the lifetime of the core object.  Rather than bloating the core objects with your feature-specific state, you can associate your feature's data with the core object using [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Supplementable.h].  This mechanism allocates your data lazily, which saves memory on pages that don't use your feature.
     23Sometimes a module needs to associate state with a core object, such as `Page` or `Navigator`.  Typically, this state doesn't interact with any of the core state and simply piggybacks on the lifetime of the core object.  Rather than bloating the core objects with your feature-specific state, you can associate your feature's data with these objects using [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Supplementable].
    2424
    25 For example, the [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/ Gampad] module needs to associate a GamepadList with Navigator.  Notice that in the [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/NavigatorGamepad.h implementation] of its [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/NavigatorGamepad.idl supplemental interface], the Gamepad module declares that NavigatorGamepad inherits from Supplement<Navigator>, which lets us store NavigatorGamepad in [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Navigator's m_supplements HashMap].
     25For example, the [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/ Gampad] module needs to associate a `GamepadList` with `Navigator`.  Notice that in the [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/NavigatorGamepad.h implementation] of its [http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/gamepad/NavigatorGamepad.idl supplemental interface], the Gamepad module declares that `NavigatorGamepad` inherits from `Supplement<Navigator>`, which lets us store a `NavigatorGamepad` in [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Navigator's m_supplements HashMap].