-
Notifications
You must be signed in to change notification settings - Fork 142
Less algorithms, better method/dfn linking #112
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs more work. I only looked at the first patch, but you told me the others are similar. The processing model section and its use feel off, either the thread on which the actual codec operation is implied, but then it's missing the fact that things need to run "in parallel", or it's all running synchronously. It must be the former.
index.src.html
Outdated
2. Run the <a>Configure Decoder</a> algorithm with |config|. | ||
2. If {{AudioDecoder/state}} is `“closed”`, throw an {{InvalidStateError}}. | ||
3. If the user agent cannot provide a codec implementation to support | ||
config, throw a {{NotSupportedError}}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be a bit less hand-wavy. It's useful to tell authors why it failed (hardware resources exhausted, resolution too big, the device/browser doesn't know how to do this, etc.). It seems like after #98, we could just refer to the concept it will introduce.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is tricky. There are a (growing) number of config options that could theoretically cause a failure. Sometimes multiple options may be equally to blame. Maybe we can define some common cases?
My hope is that the simple rejection is no less user friendly. I imagine apps will tend to walk an ordered list of configurations based on their content library (decoding) or the remote users capabilities (rtc encoding). If we tell them "hardware resources exhausted", they probably handle that the same as "unsupported codec".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Paul!
index.src.html
Outdated
2. Run the <a>Configure Decoder</a> algorithm with |config|. | ||
2. If {{AudioDecoder/state}} is `“closed”`, throw an {{InvalidStateError}}. | ||
3. If the user agent cannot provide a codec implementation to support | ||
config, throw a {{NotSupportedError}}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is tricky. There are a (growing) number of config options that could theoretically cause a failure. Sometimes multiple options may be equally to blame. Maybe we can define some common cases?
My hope is that the simple rejection is no less user friendly. I imagine apps will tend to walk an ordered list of configurations based on their content library (decoding) or the remote users capabilities (rtc encoding). If we tell them "hardware resources exhausted", they probably handle that the same as "unsupported codec".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Paul!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Paul. Holding off on new commits until we wrap the discussion on parallel queues.
So far only AudioDecoder is updated. I'll update the other interfaces pending feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again! I've resolved a number of issues we discussed over VC. As planned, the latest commits start the transition to explicit threads. I'll follow up with migrating other interfaces after review. Also, there are a few small pieces of your feedback I still plan to incorporate - out of time tonight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally this looks exactly what we need, I put in some comments, and do a last pass when the various usage of this pattern will be written.
index.src.html
Outdated
The <dfn>control thread</dfn> is the thread from which authors will construct | ||
and [=codec=] and invoke its methods. Invoking a codec's methods will typically | ||
result in the creation of [=control messages=] which are later executed on the | ||
[=codec thread=]. Each [=JavaScript realm=] has a separate control thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can never remember if it's best to talk in terms for global or realms, and why. I seem to see globals more often in this kind of spec (non ecmascript).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just applied s/Javascript realm/global object/. LMK if this is how you intended it to read. I tried to make sense of https://html.spec.whatwg.org/#realms-settings-objects-global-objects but it's very hard to grok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Paul. LMK if this looks good and I'll apply it to the other interfaces.
index.src.html
Outdated
The <dfn>control thread</dfn> is the thread from which authors will construct | ||
and [=codec=] and invoke its methods. Invoking a codec's methods will typically | ||
result in the creation of [=control messages=] which are later executed on the | ||
[=codec thread=]. Each [=JavaScript realm=] has a separate control thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just applied s/Javascript realm/global object/. LMK if this is how you intended it to read. I tried to make sense of https://html.spec.whatwg.org/#realms-settings-objects-global-objects but it's very hard to grok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've applied the feedback to the other codec interfaces and pushed some of the outstanding issues into follow up items (tightening scope to improve velocity). I think we're nearly there! A few open comments waiting for your reply/resolve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably good to merge, and we can discuss the two points I added here as followups. Thanks!
Thanks a ton! |
This flattens most of the codec algorithms into the methods where they were being called. For instance, instead of a "Configure Decoder" algorithm, we now simply have those steps listed under AudioDecoder.configure() and VideoDecoder.configure(). This does mean more copy/paste, but its much more readable for having less jumping around the document and needing less parameterization (e.g. AudioDecoder.configure() can easily refer to AudioDecoder's interface members).
I was on the fence about this vs another approach (#111) where I added more parameters to the algorithms in an attempt to get better linking for where things are used. Having done both, I definitely prefer this option. The other approach is too clever. Code re-use is great, but this is a spec so readability is more important.
Sorry this is fairly large. I did at least break it up into distinct commits for converting each of the interfaces. Also, once you read one the others are pretty obvious.
💥 Error: 500 Internal Server Error 💥
PR Preview failed to build. (Last tried on Feb 8, 2021, 11:11 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.