├── README.md
└── 0000-template.md


/README.md:
--------------------------------------------------------------------------------
1 | # hlsjs-rfcs
2 | RFCs for changes to Hls.js. Inspired by Rust's RFC repository https://github.com/rust-lang/rfcs.
3 | 


--------------------------------------------------------------------------------
/0000-template.md:
--------------------------------------------------------------------------------
 1 | - Feature Name: (fill me in with a unique ident, my_awesome_feature)
 2 | - Start Date: (fill me in with today's date, YYYY-MM-DD)
 3 | - RFC PR: (leave this empty)
 4 | - Hls.js Issue: (leave this empty)
 5 | 
 6 | # Summary
 7 | [summary]: #summary
 8 | 
 9 | One paragraph explanation of the feature.
10 | 
11 | # Motivation
12 | [motivation]: #motivation
13 | 
14 | Why are we doing this? What use cases does it support? What is the expected outcome?
15 | 
16 | # High-Level Explanation
17 | [high-level-explanation]: #high-level-explanation
18 | 
19 | Explain the proposal at a high-level, drawing br
20 | 
21 | - Introducing new named concepts.
22 | - Explaining the feature largely in terms of examples.
23 | - If applicable, provide sample error messages, deprecation warnings, or migration guidance.
24 | 
25 | 
26 | # Reference-level explanation
27 | [reference-level-explanation]: #reference-level-explanation
28 | 
29 | This is the technical portion of the RFC. Explain the design in sufficient detail that:
30 | 
31 | - Its interaction with other features is clear.
32 | - It is reasonably clear how the feature would be implemented.
33 | - Corner cases are dissected by example.
34 | 
35 | The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
36 | 
37 | # Drawbacks
38 | [drawbacks]: #drawbacks
39 | 
40 | Why should we *not* do this?
41 | 
42 | # Rationale and alternatives
43 | [rationale-and-alternatives]: #rationale-and-alternatives
44 | 
45 | - Why is this design the best in the space of possible designs?
46 | - What other designs have been considered and what is the rationale for not choosing them?
47 | - What is the impact of not doing this?
48 | 
49 | # Supported Environments
50 | [supported-environments]: #supported-environments
51 | 
52 | While not required, it is encouraged that each propsal have as wide of a support as possible.
53 | 
54 | - What browsers/device combinations are not supported by this proposal?
55 |     - Please enumerate each proposed browser API or feature which blocks support.
56 | 
57 | # Prior art
58 | [prior-art]: #prior-art
59 | 
60 | Discuss prior art, both the good and the bad, in relation to this proposal.
61 | A few examples of what this can include are:
62 | 
63 | - Does this feature exist in another player?
64 | - Has this feature been discussed in a blog post, paper, or presentation?
65 | 
66 | This section is intended to encourage you as an author to think about the lessons from other players, and provide readers of your RFC with a fuller picture.
67 | If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages.
68 | 
69 | # Unresolved questions
70 | [unresolved-questions]: #unresolved-questions
71 | 
72 | - What parts of the design do you expect to resolve through the RFC process before this gets merged?
73 | - What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
74 | - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
75 | 


--------------------------------------------------------------------------------