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

Integrate CMCD data into outgoing requests. #4346

Merged
merged 36 commits into from
Nov 10, 2021

Conversation

littlespex
Copy link
Collaborator

@littlespex littlespex commented Oct 6, 2021

This PR will...

Implement Client Media Common Data (CMCD) in outgoing media requests.

Why is this Pull Request needed?

Provide client data to deliver services and CDNs.

Are there any points in the code the reviewer needs to double check?

This changes effects the playlist and fragment loaders, so double check that the general architectural choices match the rest of the project.

Resolves issues:

Resolves #4324

Checklist

  • changes have been done against master branch, and PR does not conflict
  • new unit / functional tests have been added (whenever applicable)
  • API or design changes are documented in API.md

@littlespex littlespex marked this pull request as draft October 6, 2021 00:16
@littlespex littlespex marked this pull request as ready for review October 6, 2021 03:26
@littlespex littlespex marked this pull request as draft October 6, 2021 03:28
dsparacio
dsparacio previously approved these changes Oct 6, 2021
Copy link
Collaborator

@dsparacio dsparacio left a comment

Choose a reason for hiding this comment

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

@mangui Thanks for reviewing this! Great Talk.

- Add support for av object type
@littlespex littlespex marked this pull request as ready for review October 8, 2021 21:31
dsparacio
dsparacio previously approved these changes Oct 25, 2021
mangui
mangui previously approved these changes Nov 8, 2021
Copy link
Member

@mangui mangui left a comment

Choose a reason for hiding this comment

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

lgtm ! maybe @tjenkinson or others have other comments ?
really nice work 👏 , moreover you were really responsive to address comments/remarks 🙇

Copy link
Member

@tjenkinson tjenkinson left a comment

Choose a reason for hiding this comment

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

Agree this looks great

I've had a proper read of the spec now and have a couple more questions though

  • I'm assuming a server is supposed to first split on , but ignoring any ,'s inside "'s, to get each key/value pair, and then split each pair on the first =? If this is the case, then any custom value that is a token and has a value containing , will break the server? Are you sure custom values can be 'tokens'? If so we might need to be a bit stricter on the characters that are allowed in a token (like rejecting any containing a ,)? This spec is linked but I haven't read that in a lot of detail. We might also want to validate the key is also valid. I.e. if it contained an = that would also break things.

  • We don't support custom fields yet do we? I'm not sure using the js symbol to signal what is a token and what is a string is the best approach because I'm not sure if all browsers that could support hls.js also support symbol(?), and the purpose of symbol's is not specifically to represent tokens. I'd rather we made the api for custom fields still accept strings but support signalling if the string should be treated as a token or string.

If we don't support custom fields yet, could remove symbol handling for now and figure that out later? That also means we don't need to worry about my first point yet, because we're in control of all the keys and values.

src/controller/cmcd-controller.ts Show resolved Hide resolved
if (key === 'ot' || key === 'sf' || key === 'st') {
result = `${key}=${value}`;
} else if (type === 'string') {
result = `${key}=${JSON.stringify(value)}`;
Copy link
Member

Choose a reason for hiding this comment

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

Can we just make this the default else? Seems like the safest thing

Comment on lines 449 to 451
} else if (type === 'symbol') {
result = `${key}=${value.description}`;
} else {
Copy link
Member

Choose a reason for hiding this comment

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

If we don't support custom values yet, I think we should remove this for now, as I'm not sure we should use symbol to represent tokens and nothing should take this code path atm. See my main comment

- Make string case the fallback in serialization routine
@littlespex
Copy link
Collaborator Author

littlespex commented Nov 8, 2021

  • We don't support custom fields yet do we? I'm not sure using the js symbol to signal what is a token and what is a string is the best approach because I'm not sure if all browsers that could support hls.js also support symbol(?), and the purpose of symbol's is not specifically to represent tokens. I'd rather we made the api for custom fields still accept strings but support signalling if the string should be treated as a token or string.

The idea was pulled from an existing Structured Field library, https://www.npmjs.com/package/structured-field-values. It's an easy way to signal that a value is a token, as all other value types have one-to-one relationships with JS primitives. Otherwise we would need to write a full featured encoder, where custom fields can be registered with explicit data types (and header mappings). I'm not opposed to the idea, but I'd rather do that work in cmcd.js, and when it comes time to add custom fields to hls.js, use that library instead of the inline implementation.

  • I'm assuming a server is supposed to first split on , but ignoring any ,'s inside "'s, to get each key/value pair, and then split each pair on the first =? If this is the case, then any custom value that is a token and has a value containing , will break the server? Are you sure custom values can be 'tokens'? If so we might need to be a bit stricter on the characters that are allowed in a token (like rejecting any containing a ,)? This spec is linked but I haven't read that in a lot of detail.

We might also want to validate the key is also valid. I.e. if it contained an = that would also break things.

@wilaw would be a better person to answer some of these. Perhaps all string values should be url encoded? Full validation of key names and values could be rolled into the aforementioned encoder. For now, there is no way to pass in faulty data as custom fields have not been implemented.

If we don't support custom fields yet, could remove symbol handling for now and figure that out later? That also means we don't need to worry about my first point yet, because we're in control of all the keys and values.

Agreed. The symbol code has been removed, and the string case is the catch-all.

@tjenkinson
Copy link
Member

The symbol code has been removed, and the string case is the catch-all.

I think you forgot to push it?

The idea was pulled from an existing Structured Field library, https://www.npmjs.com/package/structured-field-values. It's an easy way to signal that a value is a token, as all other value types have one-to-one relationships with JS primitives. Otherwise we would need to write a full featured encoder, where custom fields can be registered with explicit data types (and header mappings). I'm not opposed to the idea, but I'd rather do that work in cmcd.js, and when it comes time to add custom fields to hls.js, use that library instead of the inline implementation.

Cool. I can see how it's nice that there is a 1-1 mapping between js types. I think my main concern with using symbol is whether it's supported everywhere, although I do also think it's used just because we needed another type to switch on and that existed.

@littlespex
Copy link
Collaborator Author

Sorry, pushed it to the wrong branch. All good now.

tjenkinson
tjenkinson previously approved these changes Nov 9, 2021
Copy link
Member

@tjenkinson tjenkinson left a comment

Choose a reason for hiding this comment

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

LGTM!

I assume this is a minor release not major? Anything specific we should call out in the release notes?

@littlespex
Copy link
Collaborator Author

@tjenkinson Is that question for me? If so, I would consider this a minor release. No breaking changes, no new public API methods or properties, just a new config property.

@tjenkinson
Copy link
Member

Great. @mangui look good to you? If no one has any objections I’m happy to merge and release it

@mangui
Copy link
Member

mangui commented Nov 9, 2021

sorry @tjenkinson I messed up and cancelled your approval
yes LGTM !

@tjenkinson tjenkinson merged commit 0403558 into video-dev:master Nov 10, 2021
@tjenkinson
Copy link
Member

It's in v1.1.0 now :)

@robwalch robwalch added this to the 1.1.0 milestone Nov 10, 2021
@robwalch robwalch added the CMCD label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Additional Common Media Client Data (CMCD) support.
5 participants