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

[Konstantin Tokarev]

02.08.2017, 01:12, "Maciej Stachowiak" <mjs at apple.com>:
>>  On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>>
>>  02.08.2017, 00:49, "Sam Weinig" <weinig at apple.com>:
>>>>   On Aug 1, 2017, at 6:57 AM, Dean Jackson <dino at apple.com> wrote:
>>>>
>>>>>   On 24 Jul 2017, at 22:44, Brian Burg <bburg at apple.com> 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 <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>>
>>>>   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 at lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>  --
>>  Regards,
>>  Konstantin
>>  _______________________________________________
>>  webkit-dev mailing list
>>  webkit-dev at lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin