We've split the previous explainer into the core part and the extension part (PR #645).

@littledan

We've heard that you would work on Resource Batch Preloading proposal.

We are wondering how the current core part is close enough so that Resource Batch Preloading can be explained based on the current core part (with v1 features).

If you find something which might make it difficult for us to have a Resource Batch Preloading proposal, we'd appreciate your feedback!

Regarding syntax, we've not decided anything about a new <script type=xxxx>....</script> syntax. It would be nice that we can have a good syntax which can be used either in v1 or Resource Batch Preloading proposal without much difference. We'd appreciate if you have any ideas!

Thanks!

This outline and layering looks good to me. Here is my view of next steps on my side (to rephrase what I wrote in WICG/bundle-preloading#21):

• Now that the IETF WPACK WG has adopted the bundled responses format, a new repository will be created for the bundle format. IETF WPACK WG will schedule an interrum meeting to discuss further format issues that you listed above. I am available to help @jyasskin with this repository if needed--I think it could be useful to include some of the text in the resource-bundles repository there.
• The "resource bundles" repository will transition to being the "batch prefetching" repository, to house the subset-based loading technique, now that the format is developed elsewhere. @cjtenny and I plan to work on the core proposal and have a document to share in a week or two. We apologize for our delay. This document will contain all concrete API surface details.

The API I was picturing looks quite similar to your Chromium design doc with the exception of the cache name, which I asked you about in a doc comment. What was the motivation for using a named cache, rather than having these simply be entries in the main HTTP cache?

The API I was picturing looks quite similar to your Chromium design doc with the exception of the cache name, which I asked you about in a doc comment. What was the motivation for using a named cache, rather than having these simply be entries in the main HTTP cache?

It is because the prototype CL is using Cache Storage to store each resources. If we will use the HTTP cache, we don’t need this cache name field.
But there are some benefits of using Cache Storage. The web developers can manipulate the resources in the cache using Cache Storage APIs. And also we already have good DevTools support for Cache Storage.

This is a little late, but some feedback on the plan:

1. Are there use cases apart from the WebBundles for Ad Serving #624 use case enabled by the UUID scheme? That just sounds bad overall for the web - "The ad JS can render an ad by setting the src of an iframe to a resource that's inside the bundle, but nothing on the client can read or modify the ad HTML because the resources are opaque." This is exactly the fear articulated in https://brave.com/web-standards-at-brave/3-web-bundles/ and Correct / real URLs should be enforced, to avoid breaking adblockers #551
2. Subsetting via preloading as in https://github.com/WICG/bundle-preloading/ sounds much better for letting the client decide which resources it might not want to fetch (both for caching and content blocking and just overall preventing unnecessary bytes from being downloaded). I'm very disappointed that that is not making it into v1.

Please let me know if I'm mistaken in my understanding, it's hard keeping up with the several documents related to Web Bundles/WPACK.

Thanks for the feedback!

Re 1:
#623 has a proposal using <iframe opaque>-ish, however, it seems no one is actively working on that. It seems we need a person who drives an alternative idea.

Re 2:
That's surely targeted in v2. We hope we can cover more wider use cases there.

Re 1: from an ads / #624 perspective, something similar to subresource bundles where extensions were able to read/modify the ad HTML would be completely fine. The goal is to isolate ads from (a) other ads and (b) JavaScript and running in the context of the publisher page.

For 1: The concern is that the way these UUIDs will be generated is by the web bundle toolchain, meaning that every resource, even if it's the same across different websites, will have a unique (by definition) ID. I get that current bundler tools can do that as well, but this is standardizing and incentivizing that practice and the use of literally unique identifiers is unprecedented (afaik). #623 sounds like a much better approach (and I share the concerns articulated over there as well).

For 2: it's good that it's in scope, but what is the fallback option here if a server refuses to acknowledge the proposed Resources header and always sends the entire bundle because they don't want to change infra again? Seems like the most client-friendly approach would be to do it in v1 along with the rest of the push towards subresource bundle loading instead of trying to fix things later on, given what is at stake here is clients downloading unnecessary bytes which hurts exactly those users whose needs we should be prioritizing.

Thanks.

For 1:

Re #623, tt seems there is no activity for a year. Can we expect we have a progress on that?

Re UUID approach, we're not aware whether there is any particular concern, technically or theoretically, on using UUID.
We'd appreciate if someone has a particular practical concern of using UUID, which is hopefully actionable for us.

For 2:
A good question. I think Bundle Preloading's Backward compatibility section explains that well.