On Aug 27, 2009, at 4:44 PM, Geoffrey Garen wrote:
I think it's very hard to know, a priori, what will and will not be
efficiently supportable going forward. Personally, I've been very
surprised more than once. The advantage of the C API is that we've
already signed up to support it. So, if the Qt API piggy-backs on
the C API, we'll support the Qt API implicitly, and our regression
tests will verify, for the most part, that the Qt API still works.
If the Qt API introduces new internal dependencies, we may break it
without knowing. Moreover, the performance trade-offs involved may
argue for not fixing it.
I agree with the approach of building on top of the C API.
I wanted to add as a note that we have a long-term goal to port the
other interfaces that tie directly into JSC on top of the C API
someday. In particular things like the Java and ObjC bindings. Having
these poke at the C++ internals directly has been troublesome.
JavaScriptGlue has also been troublesome but is also close to being
completely obsolete so we may not bother to upgrade it.
So this approach of building on top of the C API is something we want
to adopt ourselves, not just something we're recommending for others.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
