-
Notifications
You must be signed in to change notification settings - Fork 49
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
Use server-sent events to push remote SDP instead of polling with subscribe request #8
Comments
I have thought about these real-time updates from server, but the core of kraken is simplicity, so I try to minimize the feature set and try the best to make its API more straight forward for developers. We use kraken in production in our Mixin Messenger app, and we wrap the kraken API with our server. Our server will provide both authentication and real-time updates upon the kraken API. Thanks and yes my native language is Chinese as I have written in my first blog post. |
I am using Kraken with Openfire and using XMPP to do the real-time updates from users joining/leaving the MUC associated with the audiobridge and wont need to do the polling in my application. However, to make a Kraken web client even simpler for developers (especially those who have have experience of implementing signalling with webrtc), a push mechanism using a web standard like server-sent will be considered more elegant in the long run.
is simpler and more elegant than
Don't you think? |
Reasonable, I will try some code and if it won't make the project code over complicated I will add this feature. |
It might be more efficent to use server-sent events to push the SDP of remote peer connections to a participant instead of polling for them with subscribe requests using JavasScript setTimeout.
I am a Java developer and not a Go developer otherwise, I would have sent you a PR using one of the available Go implementations eventsource or go-sse
BTW, I am a fan of your work and I love your blogs. I appreciate your contributions to real-time communications even though WebRTC is not your main focus and English is probably not your only language of communication.
The text was updated successfully, but these errors were encountered: