[webkit-dev] Proposal: upstream the WPE port

Geoffrey Garen ggaren at apple.com
Fri Apr 21 16:01:29 PDT 2017

I think the biggest consideration here is the problems we’ve noticed in the C API that have produced poor designs that we don’t intend to support going forward.

Does the WPE port’s API need to be backwards-compatible in a source or binary way?

Is it practical for the WPE port’s API to mirror the ObjC API?


> On Apr 21, 2017, at 2:24 PM, Alex Christensen <achristensen at apple.com> wrote:
> This is exciting news, Zan!  I’m happy to see innovative new uses of WebKit.
> What kind of groups hope to use this new port?  What kind of groups hope to maintain this new port?  Will it be beneficial to the WebKit community to have their cooperative work?  I see having more groups motivated to organize things in a supportable way as positive.
> I don’t think we should just use the C API as it is.  We want to eventually remove it completely.  If we do upstream WPE, I propose doing something like one of the following:
> 1. We could make a new C API that more closely mirrors the Cocoa API, to which we only add things we have committed to support.  This should be done in collaboration with the existing API owners.
> 2. We could mark parts of the existing C API as part of the API we have committed to maintaining.  There is a lot of messy stuff in the existing C API we eventually want to remove even before we remove the whole thing (old client versions, testing-only functions, private functions that access things we want to eventually organize differently, etc.).  For example, a lot of the things in WKContextPrivate.h should be moved from a multi-process-global approach to a WKWebView/WKPage-based organization.  The basic concepts are here to stay, though.
> 3. Have third parties who use the API just deal with whatever changes we throw at them.  This could be viable if there were only a few small groups using the API, but it would hinder innovative use of the API.  We might want to reserve the right to make API breaking changes anyway, though.
>> On Apr 21, 2017, at 4:48 AM, zan at falconsigh.net wrote:
>> Hi,
>> the WebKit team at Igalia would like to propose upstreaming the WPE port
>> of WebKit, taking on the duty to maintain it alongside the GTK+ port.
>> The WPE port started in 2014 as the 'WebKit for Wayland' project inside
>> Igalia [1].  The port was derived from the GTK+ port, but avoided
>> dependency on any GUI toolkit.  It relied on the Wayland display
>> protocol for on-screen presentation.  That dependency was later dropped
>> in favor of using generic interfaces to adapt to different
>> platform-specific presentation systems.  This allows any vendor to
>> simply provide the necessary backend implementations that are tailored
>> to their platform.
>> The port is intended to be the Web platform engine of choice for
>> embedded Linux systems.  Since late 2014 Igalia has been sponsored by
>> Metrological to further develop the WPE port, targeting primarily
>> various set-top box platforms.  Miguel Gomez blogged about this effort
>> back in December [2].  The port can also address other embedded use
>> cases, for instance in-vehicle infotainment or digital signage.
>> The GTK+ and WPE ports mostly have the same dependencies except for the
>> GTK+ toolkit library.  That enables the two ports to already share a lot
>> of code.  The biggest difference between the two is that the WPE port
>> exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based
>> API.  Apart from that, the maintainers' plan is to further align the two
>> ports as much as possible, ideally simply stacking the GTK+ port on top
>> of WPE, with only a few additional tweaks for GTK+ integration.  This
>> would lessen the maintenance burden for both ports and the project as a
>> whole.
>> The WebKit team at Igalia thinks this port is on stable footing and has
>> solid prospects for the future.  That's why we'd like to join the
>> upstream community and continue our work there.
>> The patch with the port changes is in bug #171110 [3].  We have existing
>> x86_64 buildbot configurations [4] that we would have to port over to
>> the webkit.org build master.  We're planning further builder and tester
>> configurations for ARM architectures in the future.  Layout test
>> baselines would be landed separately.  (Those too would be subject to
>> alignment with the GTK+ port.)
>> We're happy to address any questions or considerations.
>> Regards,
>> Zan
>> [1]
>> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html
>> [2]
>> https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/
>> [3] https://bugs.webkit.org/show_bug.cgi?id=171110
>> [4] https://build-webkit.igalia.com/waterfall?category=WPE
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list