Skip to content
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

Normative reference to the File API working draft #57

Closed
yfuna opened this issue Mar 14, 2016 · 6 comments
Closed

Normative reference to the File API working draft #57

yfuna opened this issue Mar 14, 2016 · 6 comments
Assignees
Milestone

Comments

@yfuna
Copy link

yfuna commented Mar 14, 2016

The File API spec, which MSE refers normatively, is not yet a Recommendation or Proposed Recommendation but still a Working Draft. It means that, before we submit our transition request to PR, we have to make it stable if needed. (See Normative References)

The File API spec currently covers five features:

  1. Blob interface/object
  2. File interface/object
  3. FileList interface
  4. FileReader API
  5. Blob URL

Given that MSE only uses the fifth item, Blob URL, which is relatively a small portion and seems stable, there would be four ways we can take to achieve the stability.

  1. If WPWG has no plan to develop the spec lately, we'll ask the WPWG chairs to make it PR.
  2. If WPWG has a plan to develop the spec,
    2-a) we'll ask the WPWG chairs to split the WD into two specs, one is about Blob URL and the other is for other stuffs, and make the Blog URL spec PR.
    2-b) we'll ask the WPWG chairs to make it clear in the spec that the Blob URL part is stable and won't change in a short term.
  3. If none of above is feasible, we copy'n'paste what we need from the File API spec to MSE with a note that we will change that part to a normative reference to the File API spec when WPWG make it a PR.

Through the initial conversation with the WPWG chairs, the team found that the option 1) was not the case there(the spec currently has a development proposal in the group), and the option 2-a) was not what the chairs wanted because they think they should keep the spec inclusive on file related features.

Thus, the options left to us currently are 2-b) and 3).

I'll start analyzing these two options and list up their pros and cons, while, at the same time, welcome your thoughts on other or different options we can pursue to resolve this issue.

@yfuna yfuna self-assigned this Mar 14, 2016
@yfuna yfuna added this to the V1 milestone Mar 14, 2016
@yfuna
Copy link
Author

yfuna commented Apr 12, 2016

The MSE spec has only two referencing points to the File API spec: in the definition of the MediaSource object URL by using the Blob URL and in the extension to the createObjectURL interface which creates and binds a Blob URL to a MediaSource object.

In the File API spec, both the Blob URL and the createObjectURL interface are defined in the section 10, A URL for Blob and File reference. The content of the section is:

    1. A URL for Blob and File reference
    • 10.1. Requirements for a New Scheme
    • 10.2. Discussion of Existing Schemes
    • 10.3. Definition of blob URL Scheme
    • 10.4. Dereferencing Model for Blob URLs
    • 10.5. Creating and Revoking a Blob URL
    • 10.6. Lifetime of Blob URLs

The section 10 seemingly contains exactly what MSE needs and nothing more than that. The section looks well-isolated from other parts of the spec: it contains no reference to other parts of the File API spec except for generally mentioning the term, "blob object", in the introduction of the Blob URL concept.

So, both the option 2-b) and 3) would be feasible. However, the option 2-b) has some benefits over 3) since we don't need to prepare testing for it if we choose 2-b).

The section 10 of the File API spec has, at least, two normative reference issues: a) it refers not HTML5.1 but HTML5 and b) it has normative reference to URL Specification. We need to change the former to HTML5.1 and check the stability of the URL specification to claim the section 10 is stable when we request the transition to PR on June.

I'll ask the WPWG co-chairs if they are willing to make it clear that the section 10 is stable in File API spec and their plan about the two normative references towards September, when they are going to publish HTML5.1. If their plan is in line with ours, we could go with the option 2-b). Otherwise, we would need to choose the option 3).

@paulbrucecotton
Copy link

I'll ask the WPWG co-chairs if they are willing to make it clear that the section 10 is stable in File API spec and their plan about the two normative references towards September, when they are going to publish HTML5.1. If their plan is in line with ours, we could go with the option 2-b). Otherwise, we would need to choose the option 3).

@yfuna: Can we get a report on where this stands?

@paulbrucecotton
Copy link

@yfuna and @plehegar: Given the lack of progress on option 2-b, can we start to execute on option 3) and add the necessary material to an Appendix in MSE ASAP?

@plehegar
Copy link
Member

I think we can close this issue with no action.

As said earlier, media source uses a Blob URL, which is a string as defined in https://www.w3.org/TR/FileAPI/#DefinitionOfScheme . Now, MSE doesn't care about the details of that string. It gets one from createObjectURL and gives it directly to the src attribute. We could certainly do some tests to see if we get a Blob url scheme but we're likely to have enough interop there. Btw File API/Blob is also referenced normatively from HTML 5.0 (https://www.w3.org/TR/html5/infrastructure.html#dependencies) so we have enough precedence there to move along imho without changes.

@paulbrucecotton
Copy link

@plehegar - Please close this issue since no one has objected to your above rationale for making no change here.

@wolenetz
Copy link
Member

Closing per #57 (comment)
@plehegar or @yfuna, please re-activate if you disagree with this disposition. Based on #57 (comment), this seems unlikely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants