Changes between Version 11 and Version 12 of WebKit2


Ignore:
Timestamp:
Apr 9, 2010 8:18:14 PM (10 years ago)
Author:
dbates@webkit.org
Comment:

Spelling corrections.

Legend:

Unmodified
Added
Removed
Modified
  • WebKit2

    v11 v12  
    55== Why is it named WebKit2? ==
    66
    7 The somewhat pedestrian reason is that it's an incomptible API change from the original WebKit, so it will probably be installed as something like /System/Library/WebKit2.framework on Mac.
     7The somewhat pedestrian reason is that it's an incompatible API change from the original WebKit, so it will probably be installed as something like /System/Library/WebKit2.framework on Mac.
    88
    9 == C API: ==
     9== C API ==
    1010
    11 WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic.  In order to achieve the goal of a nonblocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. These techniques include:
     11WebKit2 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:
    1212  - Notification style client callbacks (e.g. didFinishLoadForFrame)
    1313    These inform the embedder that something has happened, but do not give
     
    4343    a HWND. On the Mac, it inherits from NSView.
    4444
    45 Note that the requirement to be fully nonblocking requires an incompatible API break - many features of most existing WebKit APIs cannot be fulfilled in a nonblocking manner. Since we needed the API break anyway, we also took advantage of the opportunity to clean up and simplify the API.
     45Note that the requirement to be fully non-blocking requires an incompatible API break - many features of most existing WebKit APIs cannot be fulfilled in a non-blocking manner. Since we needed the API break anyway, we also took advantage of the opportunity to clean up and simplify the API.
    4646
    4747== Port-Specific APIs ==
    4848
    49 We 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.
     49We plan to build a fully non-blocking 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.
    5050
    5151We are also not removing or obsoleting any of the existing port-specific APIs. WebCore will remain as-is, and all current APIs will continue to work and be fully supported. Thus, WebKit development and existing ports of WebKit will not be disrupted.
     
    7575[[Image(chromium-webkit-stack.png)]]
    7676
    77 Notice that in this case, the the process boundary is *above* the API boundary. Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblaizing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
     77Notice that in this case, the the process boundary is *above* the API boundary. Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
    7878
    7979That was an understandable choice for Google - Chrome was developed as a secret project for many years, and is deeply invested in this approach. Also, there are not any other significant API clients. There is Google Chrome, and then there is the closely related Chrome Frame.