[webkit-dev] WebKit Wishes

[Adam Barth]

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.

Adam