[webkit-dev] Proposal: upstream the WPE port

Fri Apr 21 23:14:08 PDT 2017

El vie, 21-04-2017 a las 16:01 -0700, Geoffrey Garen escribió:
> 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?

The easiest way would be to reuse the GTK+ API. WPE has the same
dependencies than the GTK+ port except for GTK+ itself. The GTK+ API of
course depend on GTK+, but only for the WebView, and a few other
fallback implementations like the file chooser, color chooser,
printing, etc, that are, in any case, optional. So, we could move 95%
of the GTK+ API to a common glib dir and reuse all that in WPE, only
adding a WebView implementation for WPE.

> Thanks,
> Geoff
> 
> > On Apr 21, 2017, at 2:24 PM, Alex Christensen <achristensen at apple.c
> > om> 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/02708
> > > 7.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
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev