[webkit-gtk] Proposal for Gobject Javascript Bridge for WebKitGtk

[Alexandre Mazari]

Hi,

Le mardi 16 août 2011 à 12:32 -0700, Martin Robinson a écrit :
> On Tue, Aug 16, 2011 at 12:18 PM, siraj razick
> <siraj.razick at collabora.co.uk> wrote:
> > void webkit_web_frame_add_gobject_to_js_window_object (WebkitWebFrame
> > *frame, const char *name, GObject *object); // add a already instantiated
> > gobject into the webframe's js context
> > void webkit_web_frame_import_namespace_to_js_window_object(WebkitWebFrame
> > *frame, const char *name, const gchar *namespace); // introduces a gir
> > namespace into the frame js context
> 
> If an API existed or exists in libseed to inject GIR namespaces and
> GObjects into any JSGlobalContextRef or JSContextRef,

It does.

>  then the API in
> WebKit isn't necessary at all. One simply has to grab the context
> during window-object-cleared and inject away.

SeedKit showcases such a usage and the proposed API would obviously be
implemented in this way.

Regarging usefulness, I guess API users are interested in having a
straight-forward way to expose lower level systems and libraries, or
most likely their own native code. The fact that Apple and Qt provide
such an API concurs in this direction.
The following not-really-proving-a-point search queries tend to confirm
this trend:
http://stackoverflow.com/search?q=addToJavaScriptWindowObject
https://github.com/search?type=Everything&language=&q=addToJavaScriptWindowObject&repo=&langOverride=&x=0&y=0&start_value=1

Implementing it at webkit level might give more context to do the right
thing regarding threading and memory management.

Obviously, that imply more code to maintain and dependencies. Also the
responsability for potential security breaches would be transfered to
webkit-gtk.

Up to you to decide if this is a fair trade.

>  This also removes all
> the ugliness of handling situations where clients call
> webkit_web_frame_add_gobject_to_js_window_object at the wrong time
> (any time before window-object-cleared).

We could alleviate such a situation by queuing the requests to delay the
actual exposition at event reception time.

> 
> > us to use it inside webkit. How ever this will create a circular dependency
> > since libseed depends on Webkit to build, To remerdy this
> > we will try to reuse only the utility methods in libseed, either by directly
> > copying over the utility mehods or by spiting libseed into two
> > as libseed and libseed-util (Something I'll have to talk with seed dev's
> > about). The reason for this is as follows
> 
> Hopefully this isn't an issue now. libwebkitgtk has been split into
> libwebkitgtk and libjavascriptcoregtk. libseed shouldn't need to link
> against libwebkitgtk.

It doesn't anymore.

> 
> > So what do you think ?. comments, reviews, idea's, and corrections a are
> > really appreciated :)
> 
> To summarize, I think there should be no new API in WebKitGTK+.
> Perhaps I'm wrong here, but it doesn't feel like the correct layer to
> have this.

I guess a qtscript equivalent, for wrapping GObjects as js objects
(without considering the WebView integration) would suite well in the
API. Where else would js-gobject integration suits more than
webkit-gtk ?
That would wildly increase the action area of webkit-gtk, notably adding
the offline local application 'market'.

Also, It would certainly benefits from the several bright eyeballs
webkit-gtk would bring and its 'gnome-agnosticism'. Seed being a
dark-corner project of Gnome, nobody but the great enthusastic
maintainers do really takes care of it. Comparing gjs and seed commits
is depressing :)

Maybe in the mean time, we'll iterate around the idea within SeedKit,
hardening access control, memory management, improving Seed, hoping
you'll reconsider your opinion at a latter stage :)
Also, get their feedback regarding the API and its impl.

Thanks for your feedback,

Happy coding,
Alexandre
> 
> --Martin
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk