Changes between Version 11 and Version 12 of WebKit2

Timestamp:

Apr 9, 2010, 8:18:14 PM (15 years ago)

Author:

dbates@webkit.org

Comment:

Spelling corrections.

WebKit2

@@ -5 +5 @@
 == Why is it named WebKit2? ==
 
-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.
+The 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.
 
-== C API: ==
+== C API ==
 
-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:
+WebKit2 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:
   - Notification style client callbacks (e.g. didFinishLoadForFrame)
     These inform the embedder that something has happened, but do not give
@@ -43 +43 @@
     a HWND. On the Mac, it inherits from NSView.
 
-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.
+Note 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.
 
 == Port-Specific APIs ==
 
-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.
+We 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.
 
 We 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.
@@ -75 +75 @@
 [[Image(chromium-webkit-stack.png)]]
 
-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.
+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 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.
 
 That 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.