Opaque identifier to contextualise handles#748
Merged
Conversation
Member
Author
|
Works for us, so merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR continues the discussion started in #741.
More precisely, it adds another property you can set when creating a handle and attaching to a plugin, namely a opaque string that can be used for different purposes: it may be used to aggregate handles of the same user or type, for instance, or to uniquely identify a user across different sessions, depending what you need to do in terms of monitoring and debugging. A very simple use cases is modifying the VideoRoom demo so that a unique random ID is generated everytime the page is loaded, and you pass it to every handle you create for the participant (the one they use to publish and to subscribe): this way, when debugging you know all those handles belong to the same person. The same approach could be used in other applications or for different purposes (e.g., to identify in event handlers or admin API a specific user using your own service identifiers).
This opaque identifier is simply a string, and Janus never uses it for anything: it just saves it, and returns it when handle info is requested via the Admin API or handle attach events are triggered to event handlers. As such, they're only useful if you plan to use those features for your own monitoring and troubleshooting applications. It's a generic string, meaning that you can put whatever you want in it: a number formatted as a string, a base64 encoded piece of information, or xml/json/whatever as long as you serialize that to a string.
I've modified the
janus.jsandjanus.nojquery.jslibraries so that you can specify it by adding aopaqueId: "<string>"property when attaching, so it should be very straightforward to use and test.Just as #741, I plan to merge this very soon, so feedback before that happens is welcome.