-
Notifications
You must be signed in to change notification settings - Fork 31
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
schema: add user.new event #995
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/livepeer/livepeer-com/wYypp7F4By7BycvE3cYrVjgXePKF |
packages/api/src/schema/schema.yaml
Outdated
@@ -209,6 +209,7 @@ components: | |||
- multistream.connected | |||
- multistream.error | |||
- multistream.disconnected | |||
- user.new |
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.
@iameli I had talked to Gioele about this in a call and he mentioned that you were against naming this event differently in our API. I think I understand where you are coming from, not to have too much divergence between our API and Mist's, but I think on this case it is not a good idea to use the same terminology here. Simply because the "user" concept already exists and has a totally different meaning in the API, even with it's own /api/user
root and all...
So when we do work on the Livepeer+Mist common API we can think of a better name for this, which makes sense in both contexts, but IMO right now using the name from one in another will only make things more confusing. Especially because currently the LP API and the Mist API have their own universe/namespaces so they will both need to be rethinked.
So @iameli WDYT? Could we rename this to something that makes more sense in the livepeer.com/api? If we were going totally free I'd go maybe with:
stream.playback.new
, but if we want to keep some level of consistency with Mist, WDYT of;stream.user.new
or maybe evenstream.playback.user.new
? (I actually like this last one)
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.
Yeah, that makes sense. Do you think there's anything in the fact that this same hook would likely be (eventually) used to authorize VoD playbacks as well, perhaps making the stream
prefix less meaningful? What about just playback.new
?
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.
Makes sense! Could also be playback.user.new
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.
Changed it to playback.user.new
both here and here!
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!
@gioelecerati Looks great. Let's sit on this for a bit until we're ready with the backend for it 👍 |
Mergin'. |
What does this pull request do? Explain your changes. (required)
Added mist user.new in the event schema and the frontend subscription dropdown.
Specific updates (required)
How did you test each of these updates (required)
Does this pull request close any open issues?
Screenshots (optional):
Checklist: