-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split the Subresource Loading with Web Bundles Explainer into two parts 1) core part and 2) extension parts. #641
Labels
Comments
Do we think subsetting belongs in the core, or as https://lowentropy.net/posts/bundles/ suggests, should we treat it as one of the first extensions? |
A good question. That's what we have to explore and decide, however, my current rough thinking (based on my early impression) is: Core:
Extensions:
Just my idea as a starting point of a discussion. |
hayatoito
added a commit
to hayatoito/webpackage
that referenced
this issue
Apr 2, 2021
…tension part (WICG#623 WICG#641) This is the almost mechanical *refactoring*, splitting the subresource-loading explainer into the core part and the extension part. The related issues are WICG#624 and WICG#641. In a follow-up PR, we might want to refine the core part so that we can write extension parts more easily, such as having well-defined terminologies and hook points.
hayatoito
added a commit
that referenced
this issue
Apr 7, 2021
#645) * Split the subresource-loading explainer into the core part and the extension part (#623 #641) This is the almost mechanical *refactoring*, splitting the subresource-loading explainer into the core part and the extension part. The related issues are #624 and #641. In a follow-up PR, we might want to refine the core part so that we can write extension parts more easily, such as having well-defined terminologies and hook points.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be better to split the Subresource Loading with WebBundles Explainer into two parts 1) core part and 2) extension parts.
We might want to split an explainer into two files, physically, so that separation (and API boundary) would become clear.
By having a core part, we hope we can find a common part in various proposals, and we can write extension parts on the top of it and discuss separately.
Related issue: #623
The text was updated successfully, but these errors were encountered: