From: Maurice O'Prey
Nathan, I know what web sockets are ...
Did I say something that was already exceedingly obvious? I'm still feeling remorse for asserting at the beginning of this thread that Web Sockets implemented a request-response cycle just like XHR. I should formally apologize to Kevin Turner and Kevin Schroeder. They tried to correct me, but I held my ground. Now I'm embarrassed. How tedious my ignorant assertions must have been!
Now I understand that once a Web Socket connection is opened, it goes in to "listen" mode. When messages are received, the "onMessage" event is triggered, and its event handler is called. The server can push data to the browser at any time while the connection remains open.
That's not the traditional HTTP request-response cycle. So I apologize to Kevin and Kevin, and any others who knew better. I apologize for any confusion I may have caused.
Nevertheless, I'm still struggling between the choices of using Web Sockets vs. XHR for streaming messages to one or many browsers the moment an event occurs on the network. I can set up the HTTP server to use persistent connections. I can use XHR to wait for broadcast messages. I don't mind connecting to an HTTP process that might spend most of it's life in a *zero CPU state, waiting for event notifications from wherever. It may not be worth the effort to develop or deploy a separate Web Socket server.
Whatever the underlying protocol, I still like the "meeting" metaphor. Maybe the only participants in the meeting are one browser and one server that forwards phone call messages, or whatever to it. I like the idea of one participant "opening" and "closing" a meeting, all participants "joining" a meeting, and all participants sending and receiving messages within that context, without every worrying about how messages are routed; they only need to know a meeting ID.
-Nathan.
midrange.com
