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

Opaque identifier to contextualise handles #748

Merged
merged 2 commits into from Jan 16, 2017

Conversation

Projects
None yet
1 participant
@lminiero
Member

lminiero commented Jan 11, 2017

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.js and janus.nojquery.js libraries so that you can specify it by adding a opaqueId: "<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.

@lminiero

This comment has been minimized.

Member

lminiero commented Jan 16, 2017

Works for us, so merging.

@lminiero lminiero merged commit 408ceb9 into master Jan 16, 2017

@lminiero lminiero deleted the handle-mapping branch Jan 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment