-
Notifications
You must be signed in to change notification settings - Fork 155
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
Make Candidate an interface #48
Conversation
This change will allow us to have custom logic and members per interface type. Relay candidates will have a completely different read loop, and candidate specific state. Relates to #47
This diff is mostly me moving files around. I would say the big thing I would like to know is if people agree with how this is implemented. Most candidates share all the same logic, but TURN needs to have its own |
Codecov Report
@@ Coverage Diff @@
## master #48 +/- ##
=========================================
+ Coverage 75.27% 75.7% +0.43%
=========================================
Files 16 20 +4
Lines 1189 1202 +13
=========================================
+ Hits 895 910 +15
+ Misses 237 235 -2
Partials 57 57
Continue to review full report at Codecov.
|
I have no strong opinion about this change mainly because I don't know what's involved for the relay candidates. If the only change is the readLoop and the state maybe you could consider abstracting that out? (something like the thing we did for the agent selector) |
Remove setLastSent and setLastReceived from Candidate interface
@hugoArregui thanks for the review (speaking of ICE reviews we need to land all your work!) As long as you think the code is still pleasant to work with I would like to keep going with it. The relay change will involve
|
Later might be better than never... I support making Candidate an interface. |
This change will allow us to have custom logic and members
per interface type. Relay candidates will have a completely different
read loop, and candidate specific state.
Relates to #47