[webkit-efl] Fwd: [webkit-qt] APIs going forward

Kenneth Rohde Christiansen kenneth.christiansen at gmail.com
Mon Feb 4 02:17:33 PST 2013


---------- Forwarded message ----------
From: Simon Hausmann <simon.hausmann at digia.com>
Date: Mon, Feb 4, 2013 at 11:13 AM
Subject: [webkit-qt] APIs going forward
To: webkit-qt at lists.webkit.org


I see an increasing demand in exposing features in the QML API. Some of those
features don't really fit naturally in it but are necessary to accomplish what
seem like basic tasks. Consequently we're facing a difficult time
between finding
an intuitive QML API, keeping things slim and maintainable but still making it
possible to do certain things.

At the same time on the implementation side we're seeing the need to improve
our layering and encapsulation. It is our intention to separate the QML
specific bits in WebKit2 from the non-QML specific bits and use a similar
layering as the other ports between then, i.e. 90% of the functionality is
covered by the C API and the remaining 10% are covered by a (Qt) port specific
view class.

So how are the two related, demand of richer API and "implementation details"
of the QML webview?

Well, if we do this right then the QML2 webview would be implemented on top of
a semi-stable 90% C based API that is shared between all ports of WebKit2.
That changes how we can perceive WebKit as a library in the system:

    (1) It looks like a "third-party" library that uses Qt, provides a mostly
C based low-level API that provides strictly speaking no stability guarantees
but gives full access to WebKit. Think of it as a library like libpng or
libicu, it just happens to use Qt under the bonnet.

    (2) A separate QML2 integration is based on the same API and connects
WebKit with QML. It comes with the full Qt API promise of stability and

The separation allows us to keep the QML API minimal and simple, following one
of the Qt principles that the common things should be easy to do. If you need
more then you'll have to fall back to the underlying library that provides a
lower level API. If done right it would be possible to combine the two, i.e.
if you'd like to use the QML webview in your application but need to fine-tune
one aspect really specific to your use-case (say the cookie storage location or
making sure that you have a dedicated web process), then you would be able to
connect the QML webview with the underlying WebKit2 C API that.

How does that sound?

If you're interested in helping us take this direction, feel free to join the
hackery and use the master bug at
https://bugs.webkit.org/showdependencytree.cgi?id=108471&hide_resolved=1 for
tracking and coordination (as well as IRC naturally).


webkit-qt mailing list
webkit-qt at lists.webkit.org

Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org


More information about the webkit-efl mailing list