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