Re: [webkit-dev] Proposal: upstream the WPE port

2017-04-21 Thread Geoffrey Garen
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  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
> 
> 

Re: [webkit-dev] Proposal: upstream the WPE port

2017-04-21 Thread Alex Christensen
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] Proposal: upstream the WPE port

2017-04-21 Thread zan
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