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? Thanks, Geoff > On Apr 21, 2017, at 2:24 PM, Alex Christensen <achristen...@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, z...@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@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
