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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-gtk
