High level APIs have the downside that they don't map well to the OS, giving up performance. To then implement something like a DB on top of it means you'll only get a fraction of the perf you would writing non-browser code.
-
If servers are shelling out to electron and not scaling then we probably need more implementations that can scale (Go comes to mind). If clients are melting then please file bugs.
Haha, I believe servers are shelling out because not even full-time compiler engineers can get the chromium implementation to build standalone 
My understanding is that the WebRTC protocol is mad complex; all the STUN,TURN stuff is tricky. Hence talk about alternatives.
-
-
(Also Go wouldn't work here, as its hard to bind to languages. An imementation in C or similar would make sense — but tricky b/c of the protocol's complexity)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
+
@juberti who should know for sure but in the browser<->server case it might be nice to be able to skip the P2P discovery and not have to implement it in a server lib. -
The server lib can be much thinner; it only needs to do ICE Lite + DTLS + SCTP. You can reuse the code from libwebrtc, or use an existing impl like libjitsi. We are working on simplifying the stack to be just ICE Lite + QUIC, which should increase the # of implementations.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.