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