[webkit-dev] Qtish API for JavaScriptCore

[Simon Hausmann]

Hi Oliver,

On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:
> Hi Simon,
>      It would really be preferred if the Qt API were just built on top
> of the standard JSC C-API, and was kept external from the repository.

We would like to utilize a Qt JSC API in the Qt API of WebKit, too. It's a big 
part of the motivation. And we want to eliminate the entire WebCore/bridge/qt 
code, which is pretty ugly.

From a dependency point of view it's a bit tricky if the Qt build of WebKit 
depends on an external library that in turn depends on JavaScriptCore from the 
same SVN repository.

That however appears to me to be independent from the issue of whether the Qt 
API uses the JSC C-API or not. (more about that below)

Would you still be okay with hosting a Qt API in the SVN if it's based on the 
C API?

> Currently the JavaScriptoCore API is completely platform and library
> independent except for the one somewhat unfortunate API referring to
> CoreFoundation but that's only exposed in the umbrella
> JavaScriptCore.h header, the JavaScript.h header is clean of any
> platform dependency.

That should be no problem indeed.

> The C API that exists already has guaranteed API and ABI
> compatibility, and this is already proving to be difficult (and in
> some cases a hindrance) to maintain as we strive to improve JSC
> performance. 

I fully believe you that this is already difficult, given the amount of 
incredible optimizations you're doing in the core. I'm curious though, where 
has the current C API bitten you?

> Adding an additional API would simply serve to make this
> task even more complex and difficult, and would have no benefit to the
> project while carrying substantial cost moving forward. 

I agree, if it harms the project in its goal of moving forward and becoming 
faster, etc. then it doesn't belong there.

> A further
> issue is that any API that binds directly to JSC internals
> realistically needs to be developed by the engineers working on the
> core engine as a developing such an API needs enormous care to not
> cause harmful long term problems.

I understand that. We've been bitten by that, too, as we've ported our 
existing API to JSC internals, to see how it can be done. The vast majority 
was straight forward as we've been careful in the original design to only 
expose what you can do in JavaScript itself. In a few places we've made 
mistakes but we've found solutions for them, too, that don't affect the 
internals in flexibility or performance. (*pokes some of the guys to elaborate 
a bit here*)

We fully agree that it doesn't make sense to use all the internals, there has 
to be a layer of abstraction to protect the engine. Currently the C API is not 
a rich enough layer for us, but I guess the best way to explain that is to file 
bug reports with patches to extend it? :)

What about functionality where the C API would slow down the C++ API but the 
internal JSC API is stable enough/good enough? I can think of the debugger for 
example.

Is there a middle ground to use as much of the C API as possible and fall back 
to internals otherwise (after discussion)?

> Over time we have added new functionality to the C-API as the need
> developed, so if there is specific functionality the Qt API would
> depend on we would be open to any suggestions.

Great :)

Simon