[webkit-dev] WebKit Wishes

[Adam Barth]

On Sun, Feb 3, 2013 at 11:46 AM, Adam Barth <abarth at webkit.org> wrote:
> On Sun, Feb 3, 2013 at 11:34 AM,  <noam.rosenthal at nokia.com> wrote:
>> On 2/3/13 7:46 PM, "ext Maciej Stachowiak" <mjs at apple.com> wrote:
>>>If you're asking about phasing it out entirely, we don't have any
>>>immediate plans to deprecate or remove the WebKit1 mac API. There are
>>>quite a few Apple and third-party apps using it, and WebKit2 is not even
>>>public API on Mac OS X currently.
>>>
>>>As for implementing aspects of the WebKit1 API in a less efficient but
>>>less WebCore-intrusive way, we could probably start doing that now, on a
>>>case-by-case basis. Do you have any specific constraints you're concerned
>>>about?
>>
>> Maybe the problem is less about the WK1 API layer and more about
>> WebCore/platform.
>> In many other projects, there is a common pattern of "platform adaptation
>> layer", where there is a clear semi-public and stable interface exposed by
>> the middleware, which allows platform adaptations to occur with less
>> intrusive dependencies. WebKit doesn't really have that notion, making it
>> impossible to "port" webkit without either participating in trunk or
>> forking.
>>
>> Platform adaptations bring a lot of benefit since they allow flexibility,
>> but they come with the cost of not being able to always achieve the most
>> straightforward vertical integration.
>> Accelerated compositing is, in my view, a successful example of a platform
>> adaptation layer. GraphicsContext is perhaps less successful.
>> A successful platform adaptation is measured by how much access is needed
>> to the underlying platform-specific implementation. For GraphicsContext,
>> for example, we call platformContext() inside rendering code way too much.
>>
>> I suggest that a good (but difficult) starting point to separating WebCore
>> and the platform adaptation is to remove all or most calls to
>> GraphicsContext::platformContext(), adding the appropriate functionality
>> as public interface to GraphicsContext, making the rendering code truly
>> platform agnostic, and perhaps later externalized as a true platform
>> adaptation interface.
>> But I would let others say whether this is feasible/desirable :)
>
> Yeah, another example is ResourceHandle, which is theoretically a
> platform-agnostic abstraction but in reality is heavily constrained by
> the capabilities of CFNetwork.

To be precise, the following WebKit API on Mac OS X is one of the root
causes of these restrictions:

webView:resource:willSendRequest:redirectResponse:fromDataSource

This API imposes the requirement that WebCore::ResourceRequest can
round-trip through NSURLRequest.  That means we're unable to improve
WebCore::ResourceRequest beyond the limitations of NSURLRequest.

Adam