Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

07.08.2017, 23:15, "Michael Catanzaro" :
> On Tue, Aug 1, 2017 at 8:57 AM, Dean Jackson  wrote:
>>  In general I think we should be more enthusiastic about removing
>>  feature flags that are guarding core parts of the Web platform. Web
>>  Timing is a great example.
>>
>>  Some others I see:
>>
>>  ENABLE_CANVAS_PATH
>>  ENABLE_CSS_COMPOSITING
>>  ENABLE_CSS_SELECTORS_LEVEL4
>>  ENABLE_FETCH_API
>>  ENABLE_GEOLOCATION
>>  ENABLE_INDEXED_DATABASE
>>  ENABLE_STREAMS_API
>>  ENABLE_CSS_SCROLL_SNAP
>>  ENABLE_WEBGL
>>  ENABLE_WEB_AUDIO
>>  ENABLE_WEB_SOCKETS
>>
>>  Dean
>
> I think nobody is using ENABLE_GAMEPAD_DEPRECATED, right? Can we remove
> that (and all the code)?

I thought there was no implementation on non-deprecated Gamepad for Linux

>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 2, 2017, at 2:18 AM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

I'm not sure ENABLE_INDEXED_DATABASE quite fits with these other things. It 
doesn't require platform-specific support, the existing back end can use a 
portable storage library. It seems more like the kind of thing that new ports 
should stub out during bring-up than a thing that we might expect to be omitted 
entirely on some ports.

> 
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.
> 
> - R. Niwa
> ___
> 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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Sergio Villar Senin]

O Mér, 02-08-2017 ás 12:43 +0300, Konstantin Tokarev escribiu:
> Also, AFAICS WebAudio is not widely used across the Web. Can anyone
> point me to real
> website which is not WebAudio demo but makes use of this API somehow?

Check www.webaudioweekly.com for several examples.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Olmstead, Don]

Web Audio is on the radar for WinCairo. I wasn't going to start working on it 
until after platform/audio ended up in PAL.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Konstantin Tokarev
Sent: Wednesday, August 2, 2017 2:44 AM
To: Ryosuke Niwa <rn...@webkit.org>; Adrien Destugues <pulkoma...@gmail.com>
Cc: WebKit-Dev <webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the 
flag?



02.08.2017, 09:19, "Ryosuke Niwa" <rn...@webkit.org>:
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues <pulkoma...@gmail.com> 
> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know 
>> we
>>  are not an upstream port anymore and have little chance of being 
>> again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and 
>> I
>>  do plan to implement some of these at some point. However, being 
>> able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then 
>> support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION, 
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they 
> all more or less require some external dependency (e.g. sqlite) and 
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge 
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you 
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia 
player" library, while ENABLE_WEB_AUDIO requires more advanced audio processing 
features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to 
real website which is not WebAudio demo but makes use of this API somehow?

>
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

--
Regards,
Konstantin
___
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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Gustavo Sverzut Barbieri]

On Tue, Aug 1, 2017 at 7:54 PM, Maciej Stachowiak  wrote:
> Chromium Embedded Framework is an obvious comparison project for use cases
> like that. CEF is arguably more popular as a bundled engine than WebKit, so
> we probably don't need more flexibility than they provide. Does CEF let you
> compile out video support?

not sure, but they do offer the video pipeline internally via
ffmpeg... thus it's not spread across ports as we do. Similar cases
come from rendering system, they force one and thus remove some
options because all ports will implement a feature, unlike here where
most features are port-dependent.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN, GTalk, FaceTime: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (16) 99354-9890
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

02.08.2017, 09:19, "Ryosuke Niwa" :
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know we
>>  are not an upstream port anymore and have little chance of being again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and I
>>  do plan to implement some of these at some point. However, being able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia 
player" library,
while ENABLE_WEB_AUDIO requires more advanced audio processing features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to 
real
website which is not WebAudio demo but makes use of this API somehow?

>
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Brady Eidson]

> On Aug 1, 2017, at 11:18 PM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

INDEXED_DATABASE can be built and used without the SQLite dependency; We have 
our own fully supported in-memory backing store for private browsing that could 
be used by any port for mainline browsing as well.
In fact, the in-memory store would be a fine default store for a port that 
doesn't even specify an IDB database directly.

At this point in the web platform and the lifecycle of IndexedDB I think it's 
problematic for any port to pretend it doesn't exist.

I support removing this one, as well.

Thanks,
 Brady

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Ryosuke Niwa]

On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  wrote:
>> Some others I see:
>>
>> ENABLE_GEOLOCATION
>> ENABLE_INDEXED_DATABASE
>> ENABLE_CSS_SCROLL_SNAP
>> ENABLE_WEBGL
>> ENABLE_WEB_AUDIO
>
> At least these are still not implemented in the Haiku port. I know we
> are not an upstream port anymore and have little chance of being again
> as I'm slowly trying to catch up with the lates 1.5 years of
> development in WebKit. But having to implement all of these would
> delay my work even more.
>
> As usual, I don't want the Haiku port to pull WebKit backwards, and I
> do plan to implement some of these at some point. However, being able
> to disable them at least for some time lets me work on other, more
> important aspects of the port first.
>
> If the compile time flags are too annoying for that, maybe an
> alternative would be to provide stub implementations, but then support
> for these features should still not be advertised to webpages if the
> port really doesn't support them.

I can see an argument for having build flags for ENABLE_GEOLOCATION,
ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
all more or less require some external dependency (e.g. sqlite) and
platform features (e.g. audio).

Perhaps we could merge some build flags though. e.g. we could merge
ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
can only enable both or neither.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Adrien Destugues]

> Some others I see:
>
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO

At least these are still not implemented in the Haiku port. I know we
are not an upstream port anymore and have little chance of being again
as I'm slowly trying to catch up with the lates 1.5 years of
development in WebKit. But having to implement all of these would
delay my work even more.

As usual, I don't want the Haiku port to pull WebKit backwards, and I
do plan to implement some of these at some point. However, being able
to disable them at least for some time lets me work on other, more
important aspects of the port first.

If the compile time flags are too annoying for that, maybe an
alternative would be to provide stub implementations, but then support
for these features should still not be advertised to webpages if the
port really doesn't support them.

--
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Michael Catanzaro]

On Tue, Aug 1, 2017 at 11:55 PM, Adrian Perez de Castro 
 wrote:
Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and 
ENABLE_WEB_AUDIO
does not need GStreamer at all, which further reduces disk and memory 
usage.
For example Buildroot includes a WebKitGTK+ recipe which can disable 
both [1]

precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.


Good point. Avoiding the GStreamer dependency is significant. I suspect 
we have more projects besides digital signage that disable both of 
these build flags, so it would probably be convenient for Igalia if 
these flags were retained. Although it is annoying to see how often we 
get bug reports about the ENABLE_VIDEO=OFF build being broken, I 
suppose that in itself is evidence that the flag is in regular use.


I'm sure we can still identify a large number of other build flags to 
be removed. There is a lot of low-hanging fruit here!


Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 6:55 PM, Adrian Perez de Castro  wrote:
> 
> Hello,
> 
> On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak  > wrote:
> 
>>> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
>>> 
>>> 02.08.2017, 00:49, "Sam Weinig" :
> On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
> 
>> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>> 
>> Hi WebKittens,
>> 
>> In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>> feature flag.
>> 
>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from 
>> shipping these features in Safari Technology Preview. I think it’s time 
>> to remove the feature flag. Are there any objections? Is there a port 
>> in-tree that’s compiling without this feature?
>> 
>> If I don’t hear anything, the flag’s removal will be tracked in 
>> .
> 
> In general I think we should be more enthusiastic about removing feature 
> flags that are guarding core parts of the Web platform. Web Timing is a 
> great example.
> 
> In general I agree that build-time feature flags should go away once all ports
> can have the feature enabled by default.
> 
> Some others I see:
> 
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS
 
 I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
 need to keep that one.
 
 I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
 platform, and how many other features depend on it.
>>> 
>>> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
>>> lots of non-browser applications that need HTML renderer (document viewers, 
>>> mail clients, instant messengers, RSS readers, etc.) which don't need 
>>> video, but also because it greatly raises the bar for implementing new 
>>> ports (e.g. recently announced Android port didn't implement video at that 
>>> time)
>> 
>> I think all of the clients you mentioned actually do need video (or at least 
>> benefit from it). In any case, most clients like that don't usually bundle 
>> their own WebKit. They use a shared copy. Usually a copy that is also used 
>> by a web browser. So if they really want to disable video, they need a 
>> runtime flag, not a compile-time flag.
> 
> Many embedded applications (embedded == not a browser, and the device does
> not have a general-purpose one) ship their own build of WebKit, almost always
> tailored to fit.
> 
> A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
> are signage panels (typically some kind of info screens in a public space),
> which most of the time show imagery and textual content, but no video or audio
> at all, running on small embedded computers where on-disk size and memory
> usage matter. For this kind of application it also makes sense to support
> ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
> nor any other kind of sound output.
> 
> Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
> does not need GStreamer at all, which further reduces disk and memory usage.
> For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
> precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

That sound somewhat more compelling to me than apps for desktop platforms that 
bundle their own WebKit.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Adrian Perez de Castro]

Hello,

On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak  wrote:

> > On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
> >
> > 02.08.2017, 00:49, "Sam Weinig" :
> >>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
> >>> 
>   On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>  
>   Hi WebKittens,
>  
>   In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>  Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>  feature flag.
>  
>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>  systems by default, and we have not experienced any fallout from 
>  shipping these features in Safari Technology Preview. I think it’s time 
>  to remove the feature flag. Are there any objections? Is there a port 
>  in-tree that’s compiling without this feature?
>  
>   If I don’t hear anything, the flag’s removal will be tracked in 
>  .
> >>> 
> >>>  In general I think we should be more enthusiastic about removing feature 
> >>> flags that are guarding core parts of the Web platform. Web Timing is a 
> >>> great example.

In general I agree that build-time feature flags should go away once all ports
can have the feature enabled by default.

> >>>  Some others I see:
> >>> 
> >>>  ENABLE_CANVAS_PATH
> >>>  ENABLE_CSS_COMPOSITING
> >>>  ENABLE_CSS_SELECTORS_LEVEL4
> >>>  ENABLE_FETCH_API
> >>>  ENABLE_GEOLOCATION
> >>>  ENABLE_INDEXED_DATABASE
> >>>  ENABLE_STREAMS_API
> >>>  ENABLE_CSS_SCROLL_SNAP
> >>>  ENABLE_WEBGL
> >>>  ENABLE_WEB_AUDIO
> >>>  ENABLE_WEB_SOCKETS
> >> 
> >> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
> >> need to keep that one.
> >> 
> >> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
> >> platform, and how many other features depend on it.
> > 
> > I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
> > lots of non-browser applications that need HTML renderer (document viewers, 
> > mail clients, instant messengers, RSS readers, etc.) which don't need 
> > video, but also because it greatly raises the bar for implementing new 
> > ports (e.g. recently announced Android port didn't implement video at that 
> > time)
> 
> I think all of the clients you mentioned actually do need video (or at least 
> benefit from it). In any case, most clients like that don't usually bundle 
> their own WebKit. They use a shared copy. Usually a copy that is also used by 
> a web browser. So if they really want to disable video, they need a runtime 
> flag, not a compile-time flag.

Many embedded applications (embedded == not a browser, and the device does
not have a general-purpose one) ship their own build of WebKit, almost always
tailored to fit.

A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
are signage panels (typically some kind of info screens in a public space),
which most of the time show imagery and textual content, but no video or audio
at all, running on small embedded computers where on-disk size and memory
usage matter. For this kind of application it also makes sense to support
ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
nor any other kind of sound output.

Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
does not need GStreamer at all, which further reduces disk and memory usage.
For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

Cheers,

--
 Adrián 

---
[1] https://git.busybox.net/buildroot/tree/package/webkitgtk/webkitgtk.mk#n37




pgpLrd2mi2v3F.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 6:32 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 02.08.2017, 01:12, "Maciej Stachowiak"  >:
>>>  On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
>>> 
>>>  02.08.2017, 00:49, "Sam Weinig" :
>   On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
> 
>>   On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>> 
>>   Hi WebKittens,
>> 
>>   In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>> feature flag.
>> 
>>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from 
>> shipping these features in Safari Technology Preview. I think it’s time 
>> to remove the feature flag. Are there any objections? Is there a port 
>> in-tree that’s compiling without this feature?
>> 
>>   If I don’t hear anything, the flag’s removal will be tracked in 
>> .
> 
>   In general I think we should be more enthusiastic about removing 
> feature flags that are guarding core parts of the Web platform. Web 
> Timing is a great example.
> 
>   Some others I see:
> 
>   ENABLE_CANVAS_PATH
>   ENABLE_CSS_COMPOSITING
>   ENABLE_CSS_SELECTORS_LEVEL4
>   ENABLE_FETCH_API
>   ENABLE_GEOLOCATION
>   ENABLE_INDEXED_DATABASE
>   ENABLE_STREAMS_API
>   ENABLE_CSS_SCROLL_SNAP
>   ENABLE_WEBGL
>   ENABLE_WEB_AUDIO
>   ENABLE_WEB_SOCKETS
 
  I think WebGL is still not supported on Windows in WebKitLegacy, so we 
 may need to keep that one.
 
  I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
 platform, and how many other features depend on it.
>>> 
>>>  I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
>>> lots of non-browser applications that need HTML renderer (document viewers, 
>>> mail clients, instant messengers, RSS readers, etc.) which don't need 
>>> video, but also because it greatly raises the bar for implementing new 
>>> ports (e.g. recently announced Android port didn't implement video at that 
>>> time)
>> 
>> I think all of the clients you mentioned actually do need video (or at least 
>> benefit from it). In any case, most clients like that don't usually bundle 
>> their own WebKit. They use a shared copy. 
> 
> That's not true for Windows, where each application is shipping its own 
> libraries, and is also not true for macOS in case port other than Mac is 
> used. And such "small" applications surely benefit from reduced size and 
> reduced dependencies. 

Chromium Embedded Framework is an obvious comparison project for use cases like 
that. CEF is arguably more popular as a bundled engine than WebKit, so we 
probably don't need more flexibility than they provide. Does CEF let you 
compile out video support?

Regards,
Maciej

> 
>> Usually a copy that is also used by a web browser. So if they really want to 
>> disable video, they need a runtime flag, not a compile-time flag.
>> 
>> The port argument is potentially more compelling. It would carry more weight 
>> if there are platforms that can't supply the required back end at all, or 
>> where support is not expected any time soon. It's ok for new ports to be 
>> initially incomplete, using stubs or extra ifdefs that we wouldn't want 
>> upstream.
>> 
>> Regards,
>> Maciej
>> 
  - Sam
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>>>  --
>>>  Regards,
>>>  Konstantin
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Michael Catanzaro]

On Tue, Aug 1, 2017 at 11:32 PM, Konstantin Tokarev  
wrote:
That's not true for Windows, where each application is shipping its 
own libraries, and is also not true for macOS in case port other than 
Mac is used. And such "small" applications surely benefit from 
reduced size and reduced dependencies.


Of course it's also not true for embedded devices.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

02.08.2017, 01:12, "Maciej Stachowiak" :
>>  On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
>>
>>  02.08.2017, 00:49, "Sam Weinig" :
   On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:

>   On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>
>   Hi WebKittens,
>
>   In WebKit, the various web-exposed timing APIs–Resource Timing, User 
> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
> feature flag.
>
>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
> systems by default, and we have not experienced any fallout from shipping 
> these features in Safari Technology Preview. I think it’s time to remove 
> the feature flag. Are there any objections? Is there a port in-tree 
> that’s compiling without this feature?
>
>   If I don’t hear anything, the flag’s removal will be tracked in 
> .

   In general I think we should be more enthusiastic about removing feature 
 flags that are guarding core parts of the Web platform. Web Timing is a 
 great example.

   Some others I see:

   ENABLE_CANVAS_PATH
   ENABLE_CSS_COMPOSITING
   ENABLE_CSS_SELECTORS_LEVEL4
   ENABLE_FETCH_API
   ENABLE_GEOLOCATION
   ENABLE_INDEXED_DATABASE
   ENABLE_STREAMS_API
   ENABLE_CSS_SCROLL_SNAP
   ENABLE_WEBGL
   ENABLE_WEB_AUDIO
   ENABLE_WEB_SOCKETS
>>>
>>>  I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
>>> need to keep that one.
>>>
>>>  I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
>>> platform, and how many other features depend on it.
>>
>>  I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
>> lots of non-browser applications that need HTML renderer (document viewers, 
>> mail clients, instant messengers, RSS readers, etc.) which don't need video, 
>> but also because it greatly raises the bar for implementing new ports (e.g. 
>> recently announced Android port didn't implement video at that time)
>
> I think all of the clients you mentioned actually do need video (or at least 
> benefit from it). In any case, most clients like that don't usually bundle 
> their own WebKit. They use a shared copy. 

That's not true for Windows, where each application is shipping its own 
libraries, and is also not true for macOS in case port other than Mac is used. 
And such "small" applications surely benefit from reduced size and reduced 
dependencies. 

>Usually a copy that is also used by a web browser. So if they really want to 
>disable video, they need a runtime flag, not a compile-time flag.
>
> The port argument is potentially more compelling. It would carry more weight 
> if there are platforms that can't supply the required back end at all, or 
> where support is not expected any time soon. It's ok for new ports to be 
> initially incomplete, using stubs or extra ifdefs that we wouldn't want 
> upstream.
>
> Regards,
> Maciej
>
>>>  - Sam
>>>
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>  --
>>  Regards,
>>  Konstantin
>>  ___
>>  webkit-dev mailing list
>>  webkit-dev@lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 02.08.2017, 00:49, "Sam Weinig" :
>>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
>>> 
  On 24 Jul 2017, at 22:44, Brian Burg  wrote:
 
  Hi WebKittens,
 
  In WebKit, the various web-exposed timing APIs–Resource Timing, User 
 Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature 
 flag.
 
  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
 systems by default, and we have not experienced any fallout from shipping 
 these features in Safari Technology Preview. I think it’s time to remove 
 the feature flag. Are there any objections? Is there a port in-tree that’s 
 compiling without this feature?
 
  If I don’t hear anything, the flag’s removal will be tracked in 
 .
>>> 
>>>  In general I think we should be more enthusiastic about removing feature 
>>> flags that are guarding core parts of the Web platform. Web Timing is a 
>>> great example.
>>> 
>>>  Some others I see:
>>> 
>>>  ENABLE_CANVAS_PATH
>>>  ENABLE_CSS_COMPOSITING
>>>  ENABLE_CSS_SELECTORS_LEVEL4
>>>  ENABLE_FETCH_API
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_STREAMS_API
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>>  ENABLE_WEB_SOCKETS
>> 
>> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
>> need to keep that one.
>> 
>> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
>> platform, and how many other features depend on it.
> 
> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
> lots of non-browser applications that need HTML renderer (document viewers, 
> mail clients, instant messengers, RSS readers, etc.) which don't need video, 
> but also because it greatly raises the bar for implementing new ports (e.g. 
> recently announced Android port didn't implement video at that time)

I think all of the clients you mentioned actually do need video (or at least 
benefit from it). In any case, most clients like that don't usually bundle 
their own WebKit. They use a shared copy. Usually a copy that is also used by a 
web browser. So if they really want to disable video, they need a runtime flag, 
not a compile-time flag.

The port argument is potentially more compelling. It would carry more weight if 
there are platforms that can't supply the required back end at all, or where 
support is not expected any time soon. It's ok for new ports to be initially 
incomplete, using stubs or extra ifdefs that we wouldn't want upstream.

Regards,
Maciej



> 
>> 
>> - Sam
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> 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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

01.08.2017, 16:58, "Dean Jackson" :
>>  On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>>
>>  Hi WebKittens,
>>
>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature 
>> flag.
>>
>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from shipping 
>> these features in Safari Technology Preview. I think it’s time to remove the 
>> feature flag. Are there any objections? Is there a port in-tree that’s 
>> compiling without this feature?
>>
>>  If I don’t hear anything, the flag’s removal will be tracked in 
>> .
>
> In general I think we should be more enthusiastic about removing feature 
> flags that are guarding core parts of the Web platform. Web Timing is a great 
> example.
>
> Some others I see:
>
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE

IndexedDB makes no sense on devices without writable storage, so I think it 
would be better to keep this flag.

> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS
>
> Dean
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 9:57 AM, Dean Jackson  wrote:
> 
> 
> 
>> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>> 
>> Hi WebKittens,
>> 
>> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
>> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>> 
>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from shipping 
>> these features in Safari Technology Preview. I think it’s time to remove the 
>> feature flag. Are there any objections? Is there a port in-tree that’s 
>> compiling without this feature?
>> 
>> If I don’t hear anything, the flag’s removal will be tracked in 
>> .
> 
> In general I think we should be more enthusiastic about removing feature 
> flags that are guarding core parts of the Web platform. Web Timing is a great 
> example. 

I agree with this sentiment. I think a lot of these should never have been 
compile time flags. They should have been runtime (or at this point not flags 
at all).

Our Feature Policy addresses this: https://webkit.org/feature-policy/ 


"In some cases, compile time flags should be used in addition to or instead of 
runtime flags:
• When merely compiling a feature in significantly impacts the 
hackability or livability of trunk.
• When a feature requires a platform-specific back end that is not 
available on all platforms.
• When some ports or platforms have resource constraints which require 
the ability to remove the feature completely from builds.
• When a feature is otherwise only relevant to some ports or platforms.

That said, runtime flags are preferred whenever feasible."

Most of the flags listed below don't meet any of these conditions, and never 
did. It sounds like a few, like WebGL, might satisfy "When a feature requires a 
platform-specific backend that is not available on all platforms".

For any new features, we should strongly consider using runtime flags whenever 
possible. For many older features, it would be great to convert them to runtime 
flags even if they aren't ready to be enabled everywhere yet. Death to 
compile-time feature flags!

> Some others I see:
> 
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_STREAMS_API

For Streams API, I think we're ready for Read Streams to be default on 
everywhere, but not yet Write Streams. I think Write Streams should be compiled 
in but runtime switched off by default until it's up to spec and fully 
qualified. (I don't remember how this maps to the flags exactly).

> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS


Regards,
Maciej




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

02.08.2017, 00:49, "Sam Weinig" :
>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
>>
>>>  On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>>>
>>>  Hi WebKittens,
>>>
>>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature 
>>> flag.
>>>
>>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>>> systems by default, and we have not experienced any fallout from shipping 
>>> these features in Safari Technology Preview. I think it’s time to remove 
>>> the feature flag. Are there any objections? Is there a port in-tree that’s 
>>> compiling without this feature?
>>>
>>>  If I don’t hear anything, the flag’s removal will be tracked in 
>>> .
>>
>>  In general I think we should be more enthusiastic about removing feature 
>> flags that are guarding core parts of the Web platform. Web Timing is a 
>> great example.
>>
>>  Some others I see:
>>
>>  ENABLE_CANVAS_PATH
>>  ENABLE_CSS_COMPOSITING
>>  ENABLE_CSS_SELECTORS_LEVEL4
>>  ENABLE_FETCH_API
>>  ENABLE_GEOLOCATION
>>  ENABLE_INDEXED_DATABASE
>>  ENABLE_STREAMS_API
>>  ENABLE_CSS_SCROLL_SNAP
>>  ENABLE_WEBGL
>>  ENABLE_WEB_AUDIO
>>  ENABLE_WEB_SOCKETS
>
> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
> need to keep that one.
>
> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
> platform, and how many other features depend on it.

I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots 
of non-browser applications that need HTML renderer (document viewers, mail 
clients, instant messengers, RSS readers, etc.) which don't need video, but 
also because it greatly raises the bar for implementing new ports (e.g. 
recently announced Android port didn't implement video at that time)

>
> - Sam
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Michael Catanzaro]

On Tue, Aug 1, 2017 at 10:39 PM, Michael Catanzaro 
 wrote:
We might want to keep ENABLE_GEOLOCATION since on our platform it 
pulls in a dependency that's not needed on embedded systems. I don't 
really care since I suspect it is small, but I bet somebody else will.


I think this applies to ENABLE_VIDEO as well. Of course that doesn't 
mean we should not consider removing these flags. Perhaps if any 
developers are working on projects that disable these flags, those 
developers should comment with statistics that measure the size impact 
of these features and their dependencies.


Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Sam Weinig]

> On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
> 
> 
> 
>> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>> 
>> Hi WebKittens,
>> 
>> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
>> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>> 
>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from shipping 
>> these features in Safari Technology Preview. I think it’s time to remove the 
>> feature flag. Are there any objections? Is there a port in-tree that’s 
>> compiling without this feature?
>> 
>> If I don’t hear anything, the flag’s removal will be tracked in 
>> .
> 
> In general I think we should be more enthusiastic about removing feature 
> flags that are guarding core parts of the Web platform. Web Timing is a great 
> example. 
> 
> Some others I see:
> 
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS


I think WebGL is still not supported on Windows in WebKitLegacy, so we may need 
to keep that one.

I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
platform, and how many other features depend on it.

- Sam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Michael Catanzaro]

We might want to keep ENABLE_GEOLOCATION since on our platform it pulls 
in a dependency that's not needed on embedded systems. I don't really 
care since I suspect it is small, but I bet somebody else will.


And I'm not sure about ENABLE_WEBGL. We have it forced on always, but 
we do allow disabling ENABLE_OPENGL and there is no dependency between 
those options. This looks like a bug in our feature defines.


The rest looks fine to me.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Dean Jackson]

> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
> 
> Hi WebKittens,
> 
> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
> 
> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
> systems by default, and we have not experienced any fallout from shipping 
> these features in Safari Technology Preview. I think it’s time to remove the 
> feature flag. Are there any objections? Is there a port in-tree that’s 
> compiling without this feature?
> 
> If I don’t hear anything, the flag’s removal will be tracked in 
> .

In general I think we should be more enthusiastic about removing feature flags 
that are guarding core parts of the Web platform. Web Timing is a great 
example. 

Some others I see:

ENABLE_CANVAS_PATH
ENABLE_CSS_COMPOSITING
ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_FETCH_API
ENABLE_GEOLOCATION
ENABLE_INDEXED_DATABASE
ENABLE_STREAMS_API
ENABLE_CSS_SCROLL_SNAP
ENABLE_WEBGL
ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev