[webkit-dev] Qtish API for JavaScriptCore

[Oliver Hunt]

On Aug 27, 2009, at 2:30 PM, Simon Hausmann wrote:

> 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?

You're right this sounds like it belongs in the WebKit Qt API layer --  
eg. WebKit/qt would be a perfectly sensible place for it to be in the  
repository.

>> 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?

The current C API allows custom implementations of more or less all  
the "internal" functions of the ES spec, which hinders our ability to  
optimise property lookups in a number of cases.

>
>> 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*)

Touching internals of JSC without intimate knowledge of how JSC works  
may cause any number of subtle (or not so subtle) correctness or  
performance problems, so these statements worry me greatly.

> 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? :)

If you're using internals of JSC your code will break.

>
> 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)?

No.  Nothing external from WebKit can rely on JSC internals -- if it  
does that injects an ABI compatibility issue going forward and  
effectively means internals of JSC suddenly become fixed.  Your  
example of a debugger is a good example of the problem -- the current  
debugger model is an artifact of ease of implementation in the old AST  
interpreter, and maintaining that ABI compatibility has hindered our  
ability to make a richer and better performing model in the Nitro  
execution engine -- adding an additional client of the current model  
would just make it even harder to improve things in future.

Like I said in my first email -- if there are shortcomings in the C  
API you need to make us aware of them if you want them to be added.

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090827/4635d868/attachment.html>