[webkit-gtk] WebKit2 API and Injected Bundle support

[Carlos Garcia Campos]

El mar, 08-05-2012 a las 12:40 +0200, Carlos Garcia Campos escribió:
[...]
> 3.- Don't expose the injected bundle API, but allow to add
> extensions/plugins. The idea is to provide a module system similar to
> GTK modules or GIO extension points. We install our own injected bundle
> lib that allows to load extensions/modules. We would also provide our
> own module to implement the features that require to use injected bundle
> like WebKitWebResource::send-request signal. In this case we have the
> same problem than 1, wrapping the whole injected bundle API would be too
> much work, so the modules/extensions might be written using the C API
> directly.

After several discussion during GUADEC and the WebKitGTK+ hackfest I
ended up implemented something similar to this idea. But instead of
using own our bundle library to implement the extension system, we use a
builtin bundle in the web process like qt does. 
You can see the current patch here:

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

And an example of how this would be used from apps here:

https://bugzilla.gnome.org/show_bug.cgi?id=684437

For now we just expose a minimal API that provides access to the GObject
DOM bindings from the web process. 

There's one last issue I would like to discuss here. In this moment, the
extension system loads all extensions found in a well known dir, so that
apps can install their extension in such dir, similar to GTK modules.
The problem is that all apps will end up with all extensions loaded,
even the ones from other applications. The idea of supporting multiple
extensions at the same time, was that there could be general extensions
useful for any application using webkit2gtk, but we don't want to load
the ephy web extension when running devhelp for example. So we need to
add an API to set the list of extensions that should be loaded. Based on
this, several ideas came to my mind:

1.- The list of extensions to load would be a list of library names, for
example: libephywebextension.so and we only load libraries with those
names.

2.- Use a list of  unique identifiers that can be extracted from the
libraries by providing another public symbol to get the id or metadata. 

3.- To avoid having to load the libraries to get their id, we could
install a GKeyFile file with the metadata (which would include the path
of the library). This way we only need to parse the metadata file and
load the given library if the id matches.

4.- Instead of using a single well known dir, apps install their
extensions in their own web extensions directory and provide the list of
directories to scan for extensions through the API instead of giving a
list of ids/libs. We could keep the global well known extensions dir for
general purpose extensions.

Any other idea? I think 4 is probably the best and easiest solution,
what do you think?

Happy New Year!
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20121231/876c0319/attachment.sig>