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.

Reply via email to