Changes between Version 2 and Version 3 of WebKit2


Ignore:
Timestamp:
Apr 9, 2010, 12:58:00 AM (15 years ago)
Author:
mjs@apple.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WebKit2

    v2 v3  
    11== WebKit2 - High Level Document ==
    22
    3 WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.
     3WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.
    44
    5 == API: ==
     5== C API: ==
    66
    7 One goal of WebKit2 is to provide a stable C-based non-blocking API.  In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. These techniques include:
     7WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic.  In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. These techniques include:
    88  - Notification style client callbacks (e.g. didFinishLoadForFrame)
    99    These inform the embedder that something has happened, but do not give
    … …  
    3838  - Native view that hooks into the platform's toolkit. On Windows, this wraps
    3939    a HWND. On the Mac, it inherits from NSView.
     40
     41== Port-Specific APIs ==
     42
     43We plan to build a fully noblocking Objective-C API for Mac OS X as a wrapper on top of the C API. We believe a similar approach may be viable for other ports.