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.
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
Permissions API #37
Permissions API #37
Changes from 4 commits
df255a2
8ce461d
45084b5
17df42c
2c01b4b
cd274c0
9386629
6569874
5cc3a22
3e25249
bf9d864
6132331
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Wondering if this should return
false
. The track is subscribed to, but just that it does not have permissions. Feels like this needs to return an enum which gives a better picture of subscription state.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.
hmm good question, I think technically it's desired to be subscribed, but tricky because clients use
subscribed
to indicate if subscription is successful and ready to be streamed.returning false probably makes more sense than true in this case.
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.
Is this preventing sending an
UpdateSubscriptions
message? Sorry, I maybe mistaking code here. But, sendingUpdateSubscriptions
should not be prevented. Server will send theSubscriptionPermissionUpdate
when there are no permissions. Note that permissions can be revoked when a track is actively subscribed. So, the server could send that update mid stream too. So, clients should always send subscription message and listen for the update from the server.I think this code is not preventing sending that message, but just wanted to elaborate.
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.
Mmm, the case I was trying to cover here was if we had previously received a subscription permission update disallowing a track, and the client decides to attempt to subscribe anyways. Should we still attempt the subscription in that case?
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.
Got it. Maybe, the log message can be something like
already subscribed, but currently does not have permissions
?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.
I think we should still let the client update the server, because it's indicating a desired state.
It does make the API a bit inconsistent, which I don't love:
Any alternatives?
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.
Discussed with @boks1971, the proposal is to turn
.subscribed
into an enum describing the current subscription status, with "subscribed, not allowed" and "subscribed" as two distinct states.Thinking about the
setSubscribed
part, I think it might be more descriptive of user intent to have separatesubscribe()
andunsubscribe()
functions, which would help clear up the inconsistency you note.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.
that sounds good. though I'm wary about breaking current users. Especially on JS. we could perhaps deprecate .subscribed, but still provide it as a way of returning
subscribeState == Subscribed
?