Skip to content

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

Merged
merged 14 commits into from
Feb 8, 2021
Merged

Conversation

chcunningham
Copy link
Collaborator

@chcunningham chcunningham commented Dec 9, 2020

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

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 [no address given] to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at api.csswg.org Port 443</address>
</body></html>

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.

Copy link
Collaborator

@padenot padenot left a 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}}.
Copy link
Collaborator

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.

Copy link
Collaborator Author

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".

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: #98, see #120

Copy link
Collaborator Author

@chcunningham chcunningham left a 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}}.
Copy link
Collaborator Author

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".

Copy link
Collaborator Author

@chcunningham chcunningham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Paul!

Copy link
Collaborator Author

@chcunningham chcunningham left a 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.
Copy link
Collaborator Author

@chcunningham chcunningham left a 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.

Copy link
Collaborator

@padenot padenot left a 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.
Copy link
Collaborator

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).

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@chcunningham chcunningham left a 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.
Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@chcunningham chcunningham left a 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.

Copy link
Collaborator

@padenot padenot left a 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!

@chcunningham chcunningham merged commit bb5e4b5 into master Feb 8, 2021
@chcunningham
Copy link
Collaborator Author

Thanks a ton!

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

Successfully merging this pull request may close these issues.

2 participants