People who were pushing for WebSockets before wanted them for realtime control. So in that case they wanted Espruino to serve up a webpage with some stuff on, which then communicated with Espruino via Websockets. For that you'd need a server inside Espruino.
My message above wasn't getting at your client implementation, that's great! - it was just because @JumJum had been looking at creating a Websocket server in JS, and I wanted to point out to anyone else that there was already a bit of the work started.
It's a good thought about the public server. I'd be a bit worried about doing it right now, but when TLS support gets put in I'll definitely think about it (although it's all more development time ;)
Having said that, if I control the server and the client, Is there a reason I should use Websockets as opposed to 'normal' sockets?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
People who were pushing for WebSockets before wanted them for realtime control. So in that case they wanted Espruino to serve up a webpage with some stuff on, which then communicated with Espruino via Websockets. For that you'd need a server inside Espruino.
My message above wasn't getting at your client implementation, that's great! - it was just because @JumJum had been looking at creating a Websocket server in JS, and I wanted to point out to anyone else that there was already a bit of the work started.
It's a good thought about the public server. I'd be a bit worried about doing it right now, but when TLS support gets put in I'll definitely think about it (although it's all more development time ;)
Having said that, if I control the server and the client, Is there a reason I should use Websockets as opposed to 'normal' sockets?