21–30 of 49 posts
Has anyone noticed "Modern and Cross Platform" usually means Golang?
This industry is insanely fad driven. Every aspect of it. Terminology, tech stacks and methodologies are all one fad after another.
Earlier quoted context omitted.
This industry is insanely fad driven. Every aspect of it. Terminology, tech stacks and methodologies are all one fad after another.
Go is over a decade old, not counting a couple of years of development in private. I'm not the biggest fan of the language but it's hard to think of it as a fad.
Earlier quoted context omitted.
This industry is insanely fad driven. Every aspect of it. Terminology, tech stacks and methodologies are all one fad after another.
Go is over a decade old, not counting a couple of years of development in private. I'm not the biggest fan of the language but it's hard to think of it as a fad.
Earlier quoted context omitted.
But it's a very similar flow as you'd normally do with a URL no? - You'd send someone a link such as http://chat.com/#id - Other person opens http://chat.com/#id redirects to another url, and this other url ( http://chat.com/#someOtherId ) is sent back to creator - Creator clicks on link again So it's just adding an extra step where the owner needs to also click on a new URL. But I agree since signalling server is ra…
Yeah, that is possible but my point is that it sorta breaks how people are used to join these kinds of meetings. The back and forth required is not the expectation most people have. If you have more people then you'd need to do this once per person, (after that they can gossip the SDP over data channels to find the other participants). Usual flow: 1. I and other people go to meet.example/DiscussImportantStuff Your pr…
Curious though if the "signalling server" can be abstracted away the same way STUN servers are: put a few URLs of signalling servers in the client app and it would choose whichever. They would all need the same echo'ing capabilities.
Point is to not maintain or have to spin up any servers for developing WebRTC apps, but making them fully autonomous.
Something like this could also be pushed forward to develop some sort of DHT around WebRTC so that this process of finding "signalling servers" can be made even more self-sufficient if the hardcoded urls in the client code are all offline.
Just a thought ️
Dumb question: what would a WASM implementation be useful for? Browsers don't expose "raw" TCP or UDP connections, so even if you have a fully working WebRTC implementation in WASM, there would be no way to connect to anything when ran inside a browser.
Or is this for WASM use outside the browser?
Interesting! Personally I am looking forward to a Rust implementation.
> Ship to Mobile, Desktop, Servers and WASM all with one code base. Dumb question: what would a WASM implementation be useful for? Browsers don't expose "raw" TCP or UDP connections, so even if you have a fully working WebRTC implementation in WASM, there would be no way to connect to anything when ran inside a browser. Or is this for WASM use outside the browser?