Quantcast

Proposal: upstream the WPE port

classic Classic list List threaded Threaded
14 messages Options
zan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: upstream the WPE port

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
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Alex Christensen-2
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, [hidden email] 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
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

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 <[hidden email]> 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, [hidden email] 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
>> [hidden email]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Carlos Garcia Campos-7
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 <[hidden email]
> > 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, [hidden email] 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
> > > [hidden email]
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > _______________________________________________
> > webkit-dev mailing list
> > [hidden email]
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Maciej Stachowiak
In reply to this post by zan

The GTK+ port has been a good WebKit citizen. And Igalia has a strong track record of WebKit contributions. So I am generally supportive of upstreaming the WPE port, as I expect it to be a net positive for the project.

I can see we will need to work out issues around the API that is exposed. In the early days of WebKit2 (or what we now call "Modern WebKit" or just plain "WebKit"), we hoped the WebKit2 C API could be a generic cross-port public API. But it seems that it hasn't worked out, and some aspects of it are regrettable legacy.

Regards,
Maciej


> On Apr 21, 2017, at 4:48 AM, [hidden email] 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
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Michael Catanzaro
In reply to this post by Carlos Garcia Campos-7
On Sat, Apr 22, 2017 at 1:14 AM, Carlos Garcia Campos
<[hidden email]> wrote:
> 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.

I'm sure reimplementing WebKitWebView without GTK+ will be a lot of
work, and I'm pretty sure it's a lot more than 5% of the current API.
But I like this plan. It will result in a dramatically better API for
WPE than what we have now. The cross-platform C API is not very good.
Our GObject-based GTK+ API is. Why didn't we consider this before? :)

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Michael Catanzaro
In reply to this post by Geoffrey Garen
On Fri, Apr 21, 2017 at 6:01 PM, Geoffrey Garen <[hidden email]>
wrote:
> 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?

I don't think so, at least not yet. The WPE port is not a widely-used
system library like the GTK+ and Mac ports. Currently it is used mainly
by our own customers. I'm sure we can handle migrating them to a new
API, if we agree to construct that new API. We were not expecting this
objection, so we have not discussed it internally yet, but this seems
like a solvable problem.

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

I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API would
be much better for us.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Brady Eidson

> On Apr 22, 2017, at 6:21 AM, Michael Catanzaro <[hidden email]> wrote:
>
> I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API would be much better for us.

I as long as the GTK and WPE ports like this plan (it appears they both are) and are both committed to see it to fruition (it appears they both are), then I fully support this.

I do *not* support adding another client of the C API, even in the interim.

Thanks,
~Brady

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Carlos Garcia Campos-7
In reply to this post by Michael Catanzaro
El sáb, 22-04-2017 a las 08:09 -0500, Michael Catanzaro escribió:

> On Sat, Apr 22, 2017 at 1:14 AM, Carlos Garcia Campos 
> <[hidden email]> wrote:
> > 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.
>
> I'm sure reimplementing WebKitWebView without GTK+ will be a lot of 
> work, and I'm pretty sure it's a lot more than 5% of the current
> API. 

I don't know why you are so sure. The idea is exactly the same to what
the C API was, a cross-platform API where ports only need to provide a
WebView implementation. WPE should already have one for the C API. Note
that I'm not proposing that WPE uses exactly the same WebKitWebView API
than the GTK+ port, but that they provide their own one. Only the
shared part of the API will be exactly the same, of course.

> But I like this plan. It will result in a dramatically better API
> for 
> WPE than what we have now. The cross-platform C API is not very
> good. 
> Our GObject-based GTK+ API is. Why didn't we consider this before? :)

Because everybody involved in WPE, devs and users, were/are happy with
the C API.

> Michael
>
>
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Carlos Garcia Campos-7
In reply to this post by Brady Eidson
El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:

> > On Apr 22, 2017, at 6:21 AM, Michael Catanzaro <[hidden email]
> > om> wrote:
> >
> > I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
> > would be much better for us.
>
> I as long as the GTK and WPE ports like this plan (it appears they
> both are) and are both committed to see it to fruition (it appears
> they both are), then I fully support this.
>
> I do *not* support adding another client of the C API, even in the
> interim.

It would be easier for us to move to the new API after the port is
upstream, since it will require refactorings in both ports GTK+ and WPE
. So, we can simply remove from the current patch anything added to the
C API (except the web view implementation or whatever is needed by WTR)
and then work on moving to the new API in follow up patches.

Are you ok with that?

> Thanks,
> ~Brady
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Brady Eidson
In reply to this post by Brady Eidson

> On Apr 24, 2017, at 2:31 AM, Carlos Garcia Campos <[hidden email]> wrote:
>
> El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
>>> On Apr 22, 2017, at 6:21 AM, Michael Catanzaro <[hidden email]
>>> om> wrote:
>>>
>>> I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
>>> would be much better for us.
>>
>> I as long as the GTK and WPE ports like this plan (it appears they
>> both are) and are both committed to see it to fruition (it appears
>> they both are), then I fully support this.
>>
>> I do *not* support adding another client of the C API, even in the
>> interim.
>
> It would be easier for us to move to the new API after the port is
> upstream, since it will require refactorings in both ports GTK+ and WPE
> . So, we can simply remove from the current patch anything added to the
> C API (except the web view implementation or whatever is needed by WTR)
> and then work on moving to the new API in follow up patches.
>
> Are you ok with that?

In the coming weeks I am actually likely to be changing and/or removing at least a few functions from the C-API.

As long as the WPE upstreaming effort is comfortable with the idea that I might be breaking them as they go… That’s fine.

Thanks,
~Brady

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Michael Catanzaro
On Mon, Apr 24, 2017 at 10:57 AM, Brady Eidson <[hidden email]>
wrote:
> In the coming weeks I am actually likely to be changing and/or
> removing at least a few functions from the C-API.
>
> As long as the WPE upstreaming effort is comfortable with the idea
> that I might be breaking them as they go… That’s fine.

Yes, we're fine with considering the C API as unstable and subject to
change at any time as per your requirements. This means we would be
landing WPE without any stable API at first.

Of course, it would be nice if you don't break the bits of the GTK+ API
that are implemented on top of the C API. We're happy to reduce our
internal use of the C API as required, we just want to keep the public
GTK+ API working.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Olivier Blin
In reply to this post by Alex Christensen-2
Hello,

I am hopping in as a WPE user.

The WPE port is gaining momentum in the set-top box world, and mainly
within the RDK consortium, which gathers many cable/TV/network operators
and software vendors.
The company I work for plans to deploy WPE on hundreds of thousands
set-top boxes soon, and we are just a small user in the RDK community.

Our contributions are pretty modest for now, but relevant for some other
ports, like the initial switch from GnuTLS to libgcrypt for crypto, or
WebP animations support (in progress).
We plan to contribute more in the coming weeks around MSE/EME for the
GStreamer backend.

Many set-top box vendors previously used QtWebKit, and WPE is now the
obvious choice since it brings the quality and stability of the Gtk port
with a lightweight approach.
WPE is very actively maintained by Igalia, and this really encourages
operators to keep in sync with upstream WebKit.
There is also a RDK working group focused on the WPE browser, with
regular meetings, where operators are committed to use and maintain WPE.

Hope this helps, it would be great to have other operators chime in here.

Thanks Zan!

Le 21/04/2017 à 23:24, Alex Christensen a écrit :
> 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.

--
Olivier Blin - SoftAtHome

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: upstream the WPE port

Olivier Blin
In reply to this post by Brady Eidson
Le 24/04/2017 à 17:57, Brady Eidson a écrit :

> >> I do *not* support adding another client of the C API, even in the
> >> interim.
> >
> > It would be easier for us to move to the new API after the port is
> > upstream, since it will require refactorings in both ports GTK+ and WPE
> > . So, we can simply remove from the current patch anything added to the
> > C API (except the web view implementation or whatever is needed by WTR)
> > and then work on moving to the new API in follow up patches.
> >
> > Are you ok with that?
>
> In the coming weeks I am actually likely to be changing and/or removing at least a few functions from the C-API.
>
> As long as the WPE upstreaming effort is comfortable with the idea that I might be breaking them as they go… That’s fine.

Hi,

I can not speak for all WPE users, as we are far from being the biggest
or most active user of WPE.
But for reference, below is a list of the C APIs that we use, a few
being specific to WPE.

WKArrayCreateAdoptingValues
WKArrayGetItemAtIndex
WKArrayGetSize
WKContextCreateWithInjectedBundlePath
WKContextGetCookieManager
WKContextSetClient
WKCookieManagerSetCookiePersistentStorage
WKErrorCopyDomain
WKErrorCopyFailingURL
WKErrorCopyLocalizedDescription
WKErrorGetErrorCode
WKPageClose
WKPageConfigurationCreate
WKPageConfigurationSetContext
WKPageConfigurationSetPageGroup
WKPageCopyActiveURL
WKPageCopyUserAgent
WKPageGroupAddUserScript
WKPageGroupCreateWithIdentifier
WKPageGroupSetPreferences
WKPageLoadURL
WKPageRunJavaScriptAlertResultListenerCall
WKPageRunJavaScriptConfirmResultListenerCall
WKPageRunJavaScriptPromptResultListenerCall
WKPageSetCustomUserAgent
WKPageSetPageInjectedBundleClient
WKPageSetPageLoaderClient
WKPageSetPageUIClient
WKPageTryClose
WKPreferencesCreate
WKPreferencesSetAllowDisplayOfInsecureContent
WKPreferencesSetLogsPageMessagesToSystemConsoleEnabled
WKRelease
WKSoupSessionSetIgnoreTLSErrors
WKSoupSessionSetPreferredLanguages
WKStringCreateWithUTF8CString
WKStringGetMaximumUTF8CStringSize
WKStringGetUTF8CString
WKStringIsEqualToUTF8CString
WKUInt64GetValue
WKURLCopyString
WKURLCreateWithBaseURL
WKURLCreateWithUTF8CString
WKUserMediaPermissionRequestAllow
WKUserMediaPermissionRequestAudioDeviceUIDs
WKUserMediaPermissionRequestVideoDeviceUIDs
WKViewCreate
WKViewGetPage


Thanks

--
Olivier Blin - SoftAtHome

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Loading...