[webkit-gtk] Arbitrary GObject exposition in a WebFrame js context... ie. Seed and WebKitGtk
amazari at igalia.com
Tue Jul 26 01:44:02 PDT 2011
SeedKit development lead me to toy with the interactions of the GObject
The eventual usage within SeedKit is to easy the burden of connecting
Different types metadata sources might be queried: GIR, lipeas
extension points classic gtype/GObject introspection or DBus
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
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++
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*
The HTML5 FileSystem specification looks like a good candidate to be
implemented in this way.
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
The implementation must carefully follow WebKit security policy to never
ever exposes dangerous native subsystems to unknown/unauthorized
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
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 ?
More information about the webkit-gtk