[webkit-gtk] Arbitrary GObject exposition in a WebFrame js context... ie. Seed and WebKitGtk

[Alexandre Mazari]

Heya,

SeedKit development lead me to toy with the interactions of the GObject
and JavaScript words and the exposition of a vanila GObject in the js
context.

The eventual usage within SeedKit is to easy the burden of connecting
existing application logic with the HTML/CSS/JavaScript UX.
Different types metadata sources might be queried: GIR, lipeas
extension points classic gtype/GObject introspection or DBus
introspection...

Thinking along this line, it occurs to me that such a mecanism might
prove interesting within webkit-gtk both as an API user and a contributor.

Indeed, a lot of recent HTML5 specifications provide access 
to lower-level resources that must in some way be made available
in the JavaScript context.
This is currently done by letting WebCore expose port-specific
implementations of *defined* implementations.
That works very well, but do not let the gtk port experiments with
arbitrary namespaces and lead to tedious GObject <-> WebCore C++
interactions.

With the "seed approach", we could write good old GObjects over our nice library,
tooling and testing facilities, and expose them using something like:

webkit_web_frame_add_object_to_global_context (WebFrame*, gchar*
variable_name, GObject*);

The HTML5 FileSystem specification looks like a good candidate to be
implemented in this way.
(http://dev.w3.org/2009/dap/file-system/pub/FileSystem/).

Two oportunities arise there. A GObject complying with the
specified DOM/JS interface could be written then exposed as-is in 
the js context under the right namespace.
Or for the more adventurous, GIO could be made fully accessible from JS
and build the specification implementation there.
Of course, GIO need to be somehow hidden to the application code after
our priviledged usage. Security needs to be deeply investigated.

An API user could rely on it to build a browser's start grid page (ala
Chrome, Opera, Safari... everyone) that needs access to the bookmark and
history data or the various about: pages accessing settings and plugins info
from the core for example. Or an IDE start page (projects, templates etc...).

even a full application UI, see SeedKit ;)

The idea is already implemented by Qt and Apple ports
http://doc.qt.nokia.com/latest/qwebframe.html#addToJavaScriptWindowObject
http://developer.apple.com/library/mac/#documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/ObjCFromJavaScript.html

The implementation must carefully follow WebKit security policy to never
ever exposes dangerous native subsystems to unknown/unauthorized
content.

The obvious path would be to reuse code from seed but a licencing issue
blocks the matter. Seed is LGPL 3+ where WebKit is strict LGPL2.
A resolution is on the as must Seed developers agreed to relicense under
compatible terms and a patch proposed. Somebody need to push the big
button :)

Still, some restructuration might be needed to make the imported Seed
code a bit more flexible and hardened security-wise.

Would such an addition be worth ? Have some brain cycle to share ?