-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
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.
@mangui Thanks for reviewing this! Great Talk.
- Add support for av object type
feature/cmcd-loaders
…teractive/hls.js into feature/cmcd-config-object * 'feature/cmcd-config-object' of https://github.com/cbsinteractive/hls.js: no message
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.
lgtm ! maybe @tjenkinson or others have other comments ?
really nice work 👏 , moreover you were really responsive to address comments/remarks 🙇
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.
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 supportsymbol
(?), and the purpose ofsymbol
'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 atoken
orstring
.
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
Outdated
if (key === 'ot' || key === 'sf' || key === 'st') { | ||
result = `${key}=${value}`; | ||
} else if (type === 'string') { | ||
result = `${key}=${JSON.stringify(value)}`; |
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.
Can we just make this the default else
? Seems like the safest thing
src/controller/cmcd-controller.ts
Outdated
} else if (type === 'symbol') { | ||
result = `${key}=${value.description}`; | ||
} else { |
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.
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
feature/cmcd-config-object
- Make string case the fallback in serialization routine
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
@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.
Agreed. The symbol code has been removed, and the |
I think you forgot to push it?
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. |
- Remove tokenized custom field code
Sorry, pushed it to the wrong branch. All good now. |
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.
LGTM!
I assume this is a minor release not major? Anything specific we should call out in the release notes?
@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. |
Great. @mangui look good to you? If no one has any objections I’m happy to merge and release it |
sorry @tjenkinson I messed up and cancelled your approval |
It's in v1.1.0 now :) |
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