Changes between Version 21 and Version 22 of Modules
- Timestamp:
- Feb 27, 2012 11:52:09 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Modules
v21 v22 5 5 == Overview == 6 6 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.7 As 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. 8 8 9 9 == Dependency diagram == … … 15 15 == Associating JavaScript APIs with "core" objects == 16 16 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 DOMWindowwould 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].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 [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]. 18 18 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.cppitself and helping to contain the MediaStream code in the MediaStream directory.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 [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. 20 20 21 21 == Associating state with "core" objects == 22 22 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.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 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]. 24 24 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 NavigatorGamepadin [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Navigator's m_supplements HashMap].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 a `NavigatorGamepad` in [http://trac.webkit.org/browser/trunk/Source/WebCore/platform/Supplementable.h Navigator's m_supplements HashMap].