[Qt] Expose the C API to access the Javascript engine

• Component: WebKit Qt
• Status: RESOLVED WONTFIX

[Benjamin Poulain]

Currently, the C API for Javascript is not exposed by QtWebkit, and the symbols are not exported. This API will remain binary compatible so there is not much risk in exposing it.

Exposing this API could be useful for cross-port development.

Here is a real-life use case: We ship several native ports of a desktop GUI application. It's a client for an Internet consumer media service and it's important to our users that we give them native-feeling ports.

Most of the application functionality is in a portable C++ library; we then write native GUI frontends against this library. We have a native OS X frontend in Cocoa, a native iPhone frontend in Cocoa Touch, and a Qt frontend that we ship for Windows and Linux.

Meanwhile, we've also bound our portable C++ library directly to Javascript, by writing against the JavaScriptCore API. We use this binding for several things:

(1) Scripting application functionality

(2) Possibly in the future, implementing some of the server-side services

(3) Implementing parts of the GUI frontends in Javascript. We have replaced some of our native windows/views/widgets with WebView instances, using HTML/CSS to create the look we want, and using our Javascript binding to receive data/events coming out of the C++ backend. Because Cocoa and Qt both provide browser widgets that are based on JavaScriptCore, we can use the same binding on both platforms.

WebKit HTML/CSS is a really great tool for creating interfaces; our users didn't even notice when we did (3), but there are big benefits for us: we only have to maintain one implementation of the widget in HTML/CSS/JS instead of separate implementations in Cocoa/ObjC++ and Qt/C++; prototyping goes much faster; we can do animation, mouseovers, and complex layouts with greater ease; we can use open source Javascript libraries; more of our team members can do the work. 

These are some of the advantages that AIR would have, but combined with the maturity of Qt/Cocoa and the ability to escape back into those toolkits when things get tough.

On Cocoa, JavaScriptCore is exposed via JavaScriptCore.framework (for accessing the API and for creating new GlobalContextRefs) and the globalContext method on WebFrame (for getting the GlobalContextRef associated with a WebKit instance.) On Qt, we have patched QWebFrame to provide a similar method, and have corrected the definition of JS_EXPORT so that the JavaScriptCore symbols are exported on all platforms (previously, they were not being exported on Windows.)

There is an effort underway to specify a standard API for binding C code to Javascript, as an alternative to engine-specific APIs like JavaScriptCore:
https://wiki.mozilla.org/ServerJS/C_API

But that's a ways off, and meanwhile, it's at least nice to be able to share code between JavaScriptCore platforms.

[Laszlo Gombos]

I think this is related discussion from webkit-dev.

https://lists.webkit.org/pipermail/webkit-dev/2009-August/009610.html

[Simon Hausmann]

(In reply to comment #0)
> Currently, the C API for Javascript is not exposed by QtWebkit, and the symbols
> are not exported. This API will remain binary compatible so there is not much
> risk in exposing it.
> 
> Exposing this API could be useful for cross-port development.

The symbols are actually exported in our builds.

I agree that there's little risk in exposing this, but it would also require making the header files actually available to developers and integrating the API docs.

I personally prefer solving bug #31863 first ;-)

[Antonio Gomes]

> I agree that there's little risk in exposing this, but it would also require
> making the header files actually available to developers and integrating the
> API docs.
> 
> I personally prefer solving bug #31863 first ;-)

I actually think that this bug is a DUP of bug 31863 . Benjamin, what do you think: is not the QtScript+JSC integration exposing enough ?

If it is not a DUP, they are dependent of each other, and would be to be worked together.

[Benjamin Poulain]

(In reply to comment #4)
> I actually think that this bug is a DUP of bug 31863 . Benjamin, what do you
> think: is not the QtScript+JSC integration exposing enough ?
> 
> If it is not a DUP, they are dependent of each other, and would be to be worked
> together.

For me it is not a duplicate. There are use cases for the low level C API, like using the same code over different WebKit ports (as geoffbugs describe).

I have added a dependency on 31863. It _might_ make sense to provide the C API via QScriptEngine. We cannot really know before 31863 is done. The other option is to give access via QWebFrame.

[Jędrzej Nowacki]

(In reply to comment #5)
> (In reply to comment #4)
> > I actually think that this bug is a DUP of bug 31863 . Benjamin, what do you
> > think: is not the QtScript+JSC integration exposing enough ?
> > 
> > If it is not a DUP, they are dependent of each other, and would be to be worked
> > together.
> 
> For me it is not a duplicate. There are use cases for the low level C API, like
> using the same code over different WebKit ports (as geoffbugs describe).
> 
> I have added a dependency on 31863. It _might_ make sense to provide the C API
> via QScriptEngine. We cannot really know before 31863 is done. The other option
> is to give access via QWebFrame.

I think that JSC C API is an implementation detail from the QtWebKit point of view, therefore it shouldn't be exposed. We plan to provide QtScript integration, which essentially should be cross platform Qtish replacement for the C API. Of course it doesn't solve problem of using the same API for a Qt and not Qt applications that was presented in comment#1, but personally I believe that is out of scope for the Qt port.

In my opinion this is a duplicate of 31863 which try to solve a similar problem in completely different way.

There is a precedence in the Qt to expose a native API?

(In reply to comment #6)
> Of course it doesn't solve problem of using the same API for a Qt
> and not Qt applications that was presented in comment#1, but personally I
> believe that is out of scope for the Qt port.

Well, I can tell you this, four months later: we're shipping it and it's really worked great for our application. (See comment #1 for the full description.) Definitely far superior to any other option that I'm aware of. And it's a trivial patch, so why not give the monkeys what they want? :)

I know that ideally (from the Qt roadmap perspective) we'd throw away our native Cocoa/Objective C frontend and ship our Qt frontend on all platforms, but that's not always a realistic possibility.

Or maybe we're the ones in the world with this problem.. I honestly have no idea. Our little patch solves our problem, so no tears will be shed either way.

Anyway, thanks for the consideration!

[Jędrzej Nowacki]

(In reply to comment #7)
> Well, I can tell you this, four months later: we're shipping it and it's really
> worked great for our application. (See comment #1 for the full description.)
> Definitely far superior to any other option that I'm aware of. And it's a
> trivial patch, 
Congratulation :-) I understand that in yours project it was easier and maybe cleaner to just patch the QtWebkit. 

> so why not give the monkeys what they want? :)
Because if we did then we would have to support it, moreover we would have to support two competitive APIs.

Cheers,
  Jędrek

[Jędrzej Nowacki]

Closing as won't fix, if you believe that we should re-discuss the issue, feel free to reopen this bug.