On Sun, Feb 3, 2013 at 11:46 AM, Adam Barth <aba...@webkit.org> wrote: > On Sun, Feb 3, 2013 at 11:34 AM, <noam.rosent...@nokia.com> wrote: >> On 2/3/13 7:46 PM, "ext Maciej Stachowiak" <m...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev