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. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
