[webkit-dev] Announcing WebKit2

[Geoffrey Garen]

> Another issue seems to be that parts of the public C API expose
> CoreFoundation, which definitely would be an issue for the other
> ports. I'm told on the side that this was just done as a quick
> solution to have something running and that if there's interest by
> other ports in using this we'd solve it with the good-old "let's add
> another abstraction layer" method, right?

I had some involvement in that decision, so I'll take a crack at answering this.

We want to avoid adding, at the API layer, new abstractions for basic types like strings, URLRequests, URLResponses, etc -- for two reasons:

1. That would require a lot of unnecessary and error-prone typing -- both for WebKit implementors and for WebKit clients.

2. That would require wasting memory and CPU to make copies at API boundaries.

Hopefully, a given port can use the same port-specific types at the API layer as it uses inside WebCore. Our theory is that, on any given platform, those are the best/easiest types for the WebKit client to use, anyway.

For example, an application should be able to pass WebKit a platform-specific URLRequest, and WebKit should be able to pass that to WebCore in turn, and WebCore should be able to pass that to its networking layer in turn -- all without any copying or conversion code. For CF ports, that's a CFURLRequest. For Qt, a QNetworkRequest. Etc.

I think the right way to achieve this will be with a simple typedef, but we won't know for sure until more ports try to adopt this API.

Best,
Geoff