Thanks for LGTM. Regarding https://bit.ly/blink-signals, we've filed a request as follows:
- Gecko: https://github.com/mozilla/standards-positions/issues/590 - WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-November/032038.html On Fri, Nov 5, 2021 at 4:25 AM Daniel Bratell <[email protected]> wrote: > LGTM to extend the experiment until 101 > > /Daniel > On 2021-10-29 10:06, Hayato Ito wrote: > > Hi Mike, > > Thanks for the comment. We appreciate that. Let me add some clarifications > and additional info. > > On Fri, Oct 29, 2021 at 3:38 AM Mike West <[email protected]> wrote: > >> On Thu, Oct 28, 2021 at 6:49 AM Daisuke Enomoto <[email protected]> >> wrote: >> >>> Contact emails >>> >>> [email protected], [email protected] >>> >>> Explainer >>> >>> >>> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md >>> >>> Specification >>> Design docs >>> >>> >>> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md >>> >>> Summary >>> >>> Provides a new approach to load a large number of resources efficiently >>> using a format that allows multiple resources to be bundled, e.g. Web >>> Bundles. >>> >>> Blink component >>> >>> Blink>Loader>WebPackaging >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader%3EWebPackaging> >>> >>> TAG review >>> >>> https://github.com/w3ctag/design-reviews/issues/616 >>> >>> (We’ll reopen this once we can have a consensus in the discussion here >>> <https://github.com/WICG/webpackage/issues/699>) >>> >>> TAG review status >>> >>> Pending >>> >>> Risks >>> Interoperability and Compatibility >>> >>> No interoperability and compatibility risk has been identified for the >>> prototype phase. This is purely a feature addition for the performance >>> optimization for now. >>> >>> It is expected that a browser which doesn’t support this feature should >>> load subresources from the network, as usual. >>> >>> Gecko: No signal >>> >>> WebKit: No signal >>> >>> Web developers: No signals >>> >> >> This might be a good time to ask, as per https://bit.ly/blink-signals. :) >> >> > > That makes sense. Let us do that soon. We'll update this thread when done. > > > >> >>> Ergonomics >>> Activation >>> >>> Developers need to package their subresoruces beforehand in order to >>> take advantage of this feature. We'll work with JS bundler ecosystems to >>> provide a plugin to package subresources as Web Bundles. >>> >>> Security >>> >>> No security risk has been identified for the prototype phase. >>> >>> Goals for experimentation >>> >>> <Key change included in the Intent to Extend> >>> >>> This Intent to Extend includes a few major changes based on the feedback >>> collected during the original OT, which are 1) <script>-based API from >>> <link>-based API, 2) new scheme: uuid-in-package, and 3) New Web Bundle >>> format version. The extension allows us to get sufficient data before >>> shipping the feature. >>> >> >> Does #1 refer to >> https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#link-based-api? >> I'm a little confused about this, as I thought we'd decided not to rely on >> <link> due to the concerns in >> https://github.com/WICG/webpackage/issues/580. >> >> > Our intention was that #1 refer to the new <script>-based API > <https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#script-based-api>, > which is aiming to replace the <link>-based API. > > > as I thought we'd decided not to rely on <link> due to the concerns in > https://github.com/WICG/webpackage/issues/580. > > That's right. Exactly for that reason, we've designed and implemented a > new <script type=webbundle> API. The design doc of <script type=webbundle> > <https://docs.google.com/document/d/1q_SodTcLuwya4cXt1gIRaVrkiaBfwWyPvkY1fqRKkgM/edit?resourcekey=0-dqrFOGVCYsg8WRZ4RFgwuw> > explains > the reason as well. > New <script>-based API will be available from M97 in the extended OT. > > Note: we plan to remove <link>-based APIs at an appropriate timing after a > good communication with OT customers. > > > >> More broadly, these changes don't appear to be included in the explainer. >> I might be misunderstanding the scope, but I'd suggest some clarification >> there so developers know what to expect. >> > > That makes sense. Since it might be difficult for developers to understand > "what's changed" by looking at one explainer, we have been trying to have a > migration guide for developers. I've just made the internal one public > here > <https://docs.google.com/document/d/1hAl7jb-a9WET_mSeHBD9HxIBUwUe65Dbyn6u6LRB61s/edit?usp=sharing>. > That's still draft, however, let us keep this up-to-date. > > It seems the original trial guide > <https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/content/browser/web_package/subresource_loading_origin_trial.md> > is > out of date. We'll update this guide too, incorporating the public > migration guide doc. Hopefully, the origin trial guide > <https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/content/browser/web_package/subresource_loading_origin_trial.md> > will > be the source of truth for this extended OT. > > > >> >> >>> See these documents for details. >>> >>> - >>> >>> <script type=webbundle> (public) >>> >>> <https://docs.google.com/document/d/1q_SodTcLuwya4cXt1gIRaVrkiaBfwWyPvkY1fqRKkgM/edit?resourcekey=0-dqrFOGVCYsg8WRZ4RFgwuw#> >>> - >>> >>> >>> >>> https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading-opaque-origin-iframes.md >>> - >>> >>> >>> >>> https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html >>> >>> >>> In addition, the original main goals remain unchanged: >>> >>> 1. Measure how this feature makes a subresource loading faster in real >>> sites. >>> >>> 2. Measure how this feature improves Ad Serving. See WebBundles for Ad >>> Serving (https://github.com/WICG/webpackage/issues/624) for details. >>> >>> 3. Collect feedback on the API surface so that we can discuss how this >>> and alternative approaches like resource-bundles ( >>> https://github.com/WICG/resource-bundles) could potentially converge in >>> the future. >>> >>> Reason this experiment is being extended >>> >>> We started with <link>-based API in the original OT to allow quicker >>> availability and confirmed the intended effect of the feature. We are >>> extending the OT to experiment with <script>-based API we had originally >>> planned along with other changes we decided to apply based on the feedback >>> collected in the original OT. >>> >>> 1) <script>-based API from <link>-based API >>> >>> 2) new scheme: uuid-in-package >>> >>> 3) Web Bundle format version >>> >>> It would be nice that we have a chance of a few more iterations so that >>> we can fix our implementation in case we find something is wrong in M97. >>> Therefore, we plan to extend the OT to M101. >>> >>> Original I2E: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ >>> >> >> >> >> >>> >>> Ongoing technical constraints >>> >>> None >>> >>> Debuggability >>> >>> Developers have the ability to test this functionality on their pages by >>> opening DevTools and selecting the Network tab. This allows the DevTools to >>> represent Web Bundles and the resources that originate from it being >>> attributed to the Web Bundle. >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? >>> >>> Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> No >>> >>> Flag name >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1082020 >>> >>> Launch bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1133108 >>> >>> Estimated milestones >>> >>> OriginTrial desktop last >>> >>> 101 >>> >>> OriginTrial desktop first >>> >>> 90 >>> >>> OriginTrial android last >>> >>> 101 >>> >>> OriginTrial android first >>> >>> 90 >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5710618575241216 >>> >>> Links to previous Intent discussions >>> >>> Intent to prototype: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wYn13HabRN0/m/L4y4iY1-AgAJ >>> >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ >>> >>> This intent message was generated by Chrome Platform Status >>> <https://www.chromestatus.com/>. >>> ----------- >>> Thanks >>> Daisuke >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698pi1FC6NCiY0KpxXuqbO8%2BeQ6dNiVkZ9OSq0LBdX089g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698pi1FC6NCiY0KpxXuqbO8%2BeQ6dNiVkZ9OSq0LBdX089g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > Hayato > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1FmjsZBVJaxhLheM025jbBG_-N4k%3DDcr1o8HQ316Tq9w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1FmjsZBVJaxhLheM025jbBG_-N4k%3DDcr1o8HQ316Tq9w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- Hayato -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_3eMBLGKX0zDsvG39FrYatys1YeZYMKY5k_AXEYEiw8nA%40mail.gmail.com.
