[webkit-gtk] [RFC] Shim loaders for script Web Extensions & new API for them

[Adrián Pérez de Castro]

Hello everybody!

First, some background: As a part of the WebKitGTK+ build process, the Web
Extensions API and the DOM bindings are processed by GObject Introspection
and are already available to be used from several languages like Python (via
PyGObject [1]), or Lua (via LGI [2]). The problem is that those APIs must be
used from the web process, and WebKit2GTK+ only supports loading compiled
shared objects (e.g. made in C/C++, maybe Vala as well).

It would be desirable to support at least Python web extensions, because
it is a very popular language to implement applications using GTK+, and
of course it would be desirable to allow using Python for implementing
custom behaviour by means of a web extension running inside the web
process. (FWIW, we already have a bug [3] for this).

Today I have done a quick experiment which demonstrates using a C shim web
extension, which uses libpython and helper functions from pygobject.h to
load a .py script which can make use of the existing DOM bindings and web
extensions API via PyGObject. You can find the proof-of-concept here:

  https://github.com/aperezdc/webkit2gtk-python-webextension-example

While this works, it would still be desirable to have this in WebKitGTK+
itself, in order to avoid projects using Python web extensions copy-pasting
and duplicating the code. Also, by maintaning the loader in WebKitGTK+ we
can maintain it up-to-date with potential changes in WebKitGTK+ (not very
likely to happen, but still), and make sure that newer versions of Python
are properly supported.


Proposed Implementation
-----------------------

(Also written at: https://bugs.webkit.org/show_bug.cgi?id=140745#c2)

We don't even need to change the public API to support loading scripts
as web extensions. In WebGtkExtensionManager::initialize() we can add
code to also search for '*.py' files in the web extensions directory.
If any is found, then it would load the Python web extension loader,
which in turn would load the '*.py' files as a separate module each,
and call their "initialize(extension, user_data)" functions.

The Python web extension loader would be a small shared object, at
"${prefix}/lib/webkit2gtk-4.0/script-extensions/libloader-python.so"
for example, and that would be linked to libpython and all the other
dependencies which are not desirable for libwebkit2gtk.so — this way
we would not force users to have Python installed. Which loaders are
built would be a compile-time option. At runtime, if the script loader
shared object cannot be used, extensions written in the corresponding
language would not be loaded instead of failing (example: libpython
is not installed). This would allow distributions to build WebKitGTK+
with support for the Python script loader, without forcing users to
always install libpython. Last but not least, if there are no Python
extensions, the Python library and its VM will never be loaded in
memory.

Note that script loaders for languages other than Python could be
added using the same machinery (Lua, JavaScript, etc.).

All Python scripts would be loaded in the same Python VM, because
it's quite messy to handle multiple VM states with libpython,
and PyGObject does not work in that scenario [4]. That shouldn't
prevent using multiple VMs for Python in the future, or for other
languages which do support multiple VM states well (like Lua).


Why not libpeas? (https://git.gnome.org/browse/libpeas/)
--------------------------------------------------------

Several reasons:

- libpeas extensions implement interfaces, while for the Web
  Extensions model it fits better to receive the WebKitWebExtension
  in the script and connect signals to it, and use the APIs normally,
  like one would do in a C extension. Not using libpeas allows script
  web extensions to use the same APIs as C extensions, and saves us
  from writing adapter code or new documentation for script web
  extensions.

- libpeas provides support for writing a configuration UI which allows
  loading/unloading/enabling/disabling plug-ins. IMHO script web
  extensions should work in the same way as C web extensions: if a
  directory for extensions is configured, WebKitGTK loads all of them.

- Using libpeas would add one additional dependency.

                     -   -   -   -   -


All comments/doubts you may have about this are welcome :)


--
 ⌨ Adrian

---
[1] https://wiki.gnome.org/action/show/Projects/PyGObject
[2] https://github.com/pavouk/lgi/
[3] https://bugs.webkit.org/show_bug.cgi?id=140745
[4] https://bugzilla.gnome.org/show_bug.cgi?id=677091
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: signature
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150826/02979a0b/attachment.sig>