Meeting minutes
Slideset: https://
<youenn_> +Present
shunya: [explains agenda] Static routing API is most important topic from our perspective
shunya: [walking through background & motivations slides]
shunya: [walking through "How to minimize the cost" slides]
<McCool_> (were web worker QoS and service worker breakouts swapped?)
<McCool_> (or maybe the calendar entries were just wrong...)
(yes, if you refresh the web calendar you'll get the updated schedule)
youenn_: we (WebKit) have been interested for quite some time and are supportive of the direction. It's exciting that this is getting to the spec level.
youenn_: it should be simple enough. If we are adding stuff progressively, we need to understand what happens when a browser only supports part of the API.
shunya: curious to learn about implementation in WebKit
youenn_: probably very similar to Chromium. Content process <-> network process <-> main process interactions. Often have to interact with the main page's process which is busy running JS. We did some improvements, moving IPCs to background threads. But still some developers are saying it is not sufficient, and I can understand that.
nick_lansley_gs1: positive comment. We have members all around the world, creating independent web applications, and running into performance issues. Anything that can improve performance and give intelligent decisions on network vs. cache or similar.
nick_lansley_gs1: is this Chromium or Chrome?
shunya: Chromium
[turning to the issues discussed on the last slide]
shunya: [explains the install-event only restriction]
youenn_: from an implementer point of view, this is good. At the end of install is when you store to disk; timing aligns well and is consistent. If we don't have a strong use case, this is a great choice.
shunya: we received a comment on GitHub from someone working on a performance improvement service third-party. The third party provides a cross-origin script which is imported via importScripts(). So maybe some conflict between first-party service worker code and importScript()s code.
youenn_: so should we add getRules() and removeRules()? Do we need to decide now?
shunya: currently we implemented only one registerRouter() call, but we changed our mind (just haven't updated implementation yet). Hopefully this is sufficient for the above multi-script use case?
Domenic: I think it will be sufficient. We can ask the person on GitHub, and if it's not, add get/remove later.
youenn_: already an existing problem [...didn't quite catch how...]
shunya: thoughts on using URLPattern?
youenn_: I question the complexity a bit. The simpler the less buggy/security issues.
Domenic: note that we're using the URLPattern mode without regexps, and the spec is a modern spec with lots of detail, so we're hopeful it won't be a problem.
shunya: it would be great to integrate with Workbox
shunya: is it useful on the edge? I guess we don't have many CDN people here, but recently lots of edge computing and CDNs uses service worker APIs.
youenn_: question on the sources. I'm less sure on race-network-and-fetch-handler.
shunya: [goes back to the slide and explains]
youenn_: like navigation preload for the fetch handler?
shunya: similar but does not wait for fetch handler execution like navigation preload does
youenn_: I was wondering about race-network-and-only-if-service-worker-is-running-run-fetch-handler. This could let service workers stay idle longer.
shunya: oh yes. It's already implemented in Chrome 117. (Some bugs.)
shunya: check out https://
Domenic: to be clear, final-form.md isn't "we're definitely building all of this", it's "let's make sure the initial version is future-compatible with what we might want"