Thanks for sending over the WICG proposal <https://github.com/WICG/proposals/issues/174> for this! I think there's now enough evidence of industry interest in this. That should enable y'all to move this to the WICG as a venue, which would resolve the IPR concerns.
On Friday, October 4, 2024 at 4:34:16 PM UTC+2 Rick Byers wrote: The main reason I'm personally gung-ho on shipping this is that, as far as I can tell, it has extremely low interoperability and compatibility risk. This is just metadata that influences performance heuristics and (despite some risk) all browsers tweak performance heuristics all the time without necessarily having any public / transparent process for doing so. Even in the case of developer-influenced heuristics like PIFE, is there any precedent for following a standards track? This proposal seems strictly better in that regard in terms of plausibly becoming on a standards track someday as interest grows, so taking a step in that direction seems like a net positive to me. Marja, can you confirm that, should we get feedback later for adjusting the syntax and other details, we can easily change our implementation after shipping? Worst case we support both old and new formats for ~2 milestones while partners who really care about the perf wins they're seeing update, right? Of course I agree that if we can meet the bar now for getting this into an IPR-protected venue, then absolutely we should. I know we've reached out to some non-Google developers to gauge interest and haven't yet found anyone interested in experimenting. It's good to poke on that a little more (eg. maybe this <https://twitter.com/RickByers/status/1842204146687934513> will turn up someone in the web perf community), but I don't think we should block indefinitely on it as long as we have evidence of clear user-benefit. So in terms of demonstrating the benefit, Marja what data can you share about performance improvements that you've seen from properties who have tested this? From all our work on performance of native applications (like Chrome), I think it should be pretty obvious that PGO can lead to meaningful user-observable performance wins, but I do agree that we should be able to characterize those wins in a concrete public setting before shipping. Rick On Fri, Oct 4, 2024 at 9:12 AM Mike Taylor <miketa...@chromium.org> wrote: On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote: miketaylr@: It's very likely that the privacy & security reviews will be very straightforward in comparison to the API owners approval. This is essentially a JavaScript feature (though, not a semantics changing one) so it doesn't have privacy implications. Security-wise, it's much less risky than other V8 features on average, so I don't expect much work to be coming from that direction either. That's why I kicked off the API owner discussion first, since that's the most interesting one. Would it be ok to do the privacy & security reviews only after this discussion has converged? We ask that everyone *request* the various review gates before we give OWNERs approvals - but we don't block on the resolution of said reviews. Also, if you already have internal reviews (which is likely true given that you've already run an Origin Trial), you can just link to the internal launch bug and use the Request N/A button. What Mike said. It's better to kick off these reviews at the start of the I2S, and API owners are unlikely to approve this without those reviews started. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/ chromium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728- 64bf28201636%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728-64bf28201636%40chromium.org?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cd5bc709-2560-46b4-88c3-3b2e9234f2e2n%40chromium.org.
