You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can discuss this after 2020 if necessary, but I already had the write-up finish, so I wanted to go ahead and post it.
I’ve been working on a “bare metal” version of WebRTC, and it’s currently 1.8kb compressed and still does not handle: reconnection, greedy/patient partner assignment, or any other “edge” cases across browsers (which there seem to be more than a few). Asking users to code WebRTC support themselves (in addition) to their game is kind of a nightmare. You’re asking for potentially broken implementations that are likely to result in broken entries.
We don’t require users to code a web socket implementation from scratch. We allow socket.io because it makes sense in the Server category. If we now allow WebRTC, why not allow a single well-respected library that abstracts the ‘low-level’ details so people can focus on their game, not low-level networking code that varies from browser to browser?
Not having a “go to” library is really going to discourage entries from actually using WebRTC, which defeats the purpose of allowing it.
What about the other categories?
I’m not sure this has any relevance to other categories. You need TURN and a network just to identify your “outside” IP address. Technically that doesn’t require a server (you could copy and paste or QR-code the “offer”) but in the “Server” category it’s a pretty obvious/easy choice to use socket.io for “signaling” part.
If we want to allow QR-code style usage of WebRTC in other categories, then make it “free” in those other categories. If not, don’t. I’m not sure why this should have any bearing on it’s allowed use in the Server category.
It’s also possible that for 2020 we allow simple-peer only for Server and then next year we allow it for the other categories as well. That really just seems a policy decision.
The text was updated successfully, but these errors were encountered:
We can discuss this after 2020 if necessary, but I already had the write-up finish, so I wanted to go ahead and post it.
I’ve been working on a “bare metal” version of WebRTC, and it’s currently 1.8kb compressed and still does not handle: reconnection, greedy/patient partner assignment, or any other “edge” cases across browsers (which there seem to be more than a few). Asking users to code WebRTC support themselves (in addition) to their game is kind of a nightmare. You’re asking for potentially broken implementations that are likely to result in broken entries.
We don’t require users to code a web socket implementation from scratch. We allow socket.io because it makes sense in the Server category. If we now allow WebRTC, why not allow a single well-respected library that abstracts the ‘low-level’ details so people can focus on their game, not low-level networking code that varies from browser to browser?
Not having a “go to” library is really going to discourage entries from actually using WebRTC, which defeats the purpose of allowing it.
What about the other categories?
I’m not sure this has any relevance to other categories. You need TURN and a network just to identify your “outside” IP address. Technically that doesn’t require a server (you could copy and paste or QR-code the “offer”) but in the “Server” category it’s a pretty obvious/easy choice to use socket.io for “signaling” part.
If we want to allow QR-code style usage of WebRTC in other categories, then make it “free” in those other categories. If not, don’t. I’m not sure why this should have any bearing on it’s allowed use in the Server category.
It’s also possible that for 2020 we allow
simple-peer
only for Server and then next year we allow it for the other categories as well. That really just seems a policy decision.The text was updated successfully, but these errors were encountered: