[webkit-gtk] Breaking the API/ABI for 2.6

Adrian Perez de Castro aperez at igalia.com
Fri Jun 6 06:11:51 PDT 2014


José Dapena Paz <jdapena at igalia.com> writes:

> El vie, 06-06-2014 a las 12:16 +0300, Adrian Perez de Castro escribió:
>
>> This will make it possible to avoid having to use Web Extensions
>> for simple use cases where user script messages are enough — and
>> save time for developers migrating to WebKit2 now that WebKit1
>> is not developed anymore. Last but not least, let's not forget
>> that for the moment only we only load C/C++ Web Extensions and
>> no built-in support is available for other languages, so having
>> support for the user script messages API will benefit all the
>> languages with GObject-Introspection support.
>
> And still it is a bad solution if the things we are moving to UI process
> are bigger than a couple of very basic things.

Indeed. The documentation will recommend *not* using the user script
messages API for big amounts of data. The main use case would be event
signaling from the web process to the UI process, when the data passed
over the wire will be small. Web Extensions would still be the way to
go for all over cases — either using D-Bus (as Epiphany does), or other
custom IPC mechanisms on a case-by-case basis (which is the way anyway
even using Web Extensions for passing big data around).

Also, another thing that I want to put very clear in the user script
messages API documentation is that “window.webkit.<name>.postMessage()”
can return before the UI process receives and processes the data, and
that it does not receive data back from the UI process (it is a one-way
communication facility).

> So I think we should have the messages API. But it would be important to
> also think on how to easy implement web process plugins:
> * It seems the most obvious thing "implementation side" is using JS.

This can be easily done with user scripts. It is not as powerful as
writing a Web Extension, but it should work for most user scripts
(as in Greasemonkey [1], and provided by userscripts.org [2]).

> * But about content plugins (i.e. URI handlers, etc), how to implement
> them through scripting? A kind of minimal injected bundle API? In the
> end this should go to network process even.

Instead of proving an alternative/minimal API, I would rather add
support for a Python Web Extension loader (and/or a JS Web Extension
loader).

> So, instead of using the solutions that are more similar to what we were
> used to do in a WebKit1 scenario, my question is... How thing should
> look like in a WebKit2 scenario? How to preserve the processes
> separation in the best way, even for the implementation of small apps?

IMHO:

1. Simple rendezvous communication, passing small data around:
   webkit_web_view_run_javascript() + window.webkit.<name>.postMessage()

2. Otherwise, use a Web Extension.

   2a. C/C++ Web Extensions are already supported.
   2b. We should provide at some point a better developer story for
       Python/JS/others Web Extensions.

Cheers,


-Adrian

---
[1] http://www.greasespot.net/
[2] http://userscripts.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20140606/6512dad8/attachment-0001.sig>


More information about the webkit-gtk mailing list