5 ms·

> Each inbound WebSocket connection runs your program in a dedicated process. Connections are isolated by process. I see you and 10,900 other "software develop

> Each inbound WebSocket connection runs your program in a dedicated process. Connections are isolated by process. I see you and 10,900 other "software developers" get the point of WebSocket. It's especially "impressive" when you written the whole thing in Go and could have used goroutines and channels, which could easily handle hundreds of thousand of connections (maybe millions). Terrible design! For a long time I thought every software developer must be smart, but a lot of them don't see the big picture very often. Why this bothers me so much? You created something that a lot of developers think is good enough, so less innovation will happen and more and more slow websites will appear because of tech like this...

willeh 8y ago
There are definitely use cases for this, for instance you might have some command line application that uses standard io. Sure it might be adapted to have support for web sockets natively, but this of course takes time. And as the old adage goes time is money. And sure you might be upset by "slow" websites, but for the small consultancy productising their scripts, it might make them - dare I say it, a quick buck. In the end the invisible hand of the market decides how much money is invested making websites fast and that is what guides the design of the technology being developed. Perhaps it is you who fail to see the big picture.
rakoo 8y ago
The business logic is all outside of websocketd. There is no standard as to how to do this, so obviously the simplest way is to mimic CGI. Invocation happens when the status quo isn't enough, and the status quo until now was that there was no 10-second way to send whatever you want through websocket. It can happen now, and you can be the one to propose some better protocol for a websocket endpoint and a business logic process to discuss.
houseinthewoods 8y ago
I've never felt a stronger sense of https://xkcd.com/386/ https://xkcd.com/386/ in my life. Why are you being so cynical? The author made a tool with no interface that turns any program into a websocket server, making no claim that it can directly replace production servers focused on scale. What are you complaining about? Who hurt you?

willeh 8y ago

There are definitely use cases for this, for instance you might have some command line application that uses standard io. Sure it might be adapted to have support for web sockets natively, but this of course takes time. And as the old adage goes time is money. And sure you might be upset by "slow" websites, but for the small consultancy productising their scripts, it might make them - dare I say it, a quick buck. In the end the invisible hand of the market decides how much money is invested making websites fast and that is what guides the design of the technology being developed. Perhaps it is you who fail to see the big picture.

rakoo 8y ago

The business logic is all outside of websocketd. There is no standard as to how to do this, so obviously the simplest way is to mimic CGI. Invocation happens when the status quo isn't enough, and the status quo until now was that there was no 10-second way to send whatever you want through websocket. It can happen now, and you can be the one to propose some better protocol for a websocket endpoint and a business logic process to discuss.

houseinthewoods 8y ago

I've never felt a stronger sense of https://xkcd.com/386/ https://xkcd.com/386/ in my life. Why are you being so cynical? The author made a tool with no interface that turns any program into a websocket server, making no claim that it can directly replace production servers focused on scale. What are you complaining about? Who hurt you?