[Webkit-unassigned] [Bug 30556] [Qt] Expose the C API to access the Javascript engine

Tue Oct 20 14:14:06 PDT 2009

https://bugs.webkit.org/show_bug.cgi?id=30556

geoffbugs at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |geoffbugs at gmail.com

--- Comment #1 from geoffbugs at gmail.com  2009-10-20 14:14:06 PDT ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.