3 ms·

Ok, but then why the focus on the "websocket" which is just a simple protocol over TCP. Why not an "universal" app server which can handle also other transport

Ok, but then why the focus on the "websocket" which is just a simple protocol over TCP. Why not an "universal" app server which can handle also other transport layers. We already have these kind of frameworks (and "websocket" is just a single line on their endless feature list) Edit: anyway, i see where this module would fit, i was just curious why we need to use for everything a foreign component and create more dependencies for our projects instead of developing in-house such trivial modules

neomantra 11y ago
The specification says the WebSocket is the default transport; some implementations also support Unix Sockets and Unix Pipes. I have my own in-house WebSocket (raw, not WAMP.ws) application server and a very thin client-side API wrapper around raw WebSockets; it performs PubSub and some RPC. It's not rocket science but it's also not trivial. I might consider migrating that custom subprotocol to this framework. It looks like they have thought carefully about the general issues with PubSub/RPC and it will be easier to scale my use (as in expanding my RPC APIs, not in terms of # of clients). I can focus on my data and APIs, not on the substrate. Hopefully an ecosystem of designers/implementors/users emerges that make this thing awesome. Of course, I've thought that about other libraries and frameworks and it went nowhere, so we'll see.