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 ? _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
