- From: Frode Børli <frode@seria.no>
- Date: Sat, 26 Jul 2008 01:48:46 +0200
I think we should agree on which features that WebSockets need to provide before deciding on a protocol or method of achieving the goals. Basically I want these features from WebSockets: 1. The server side script that generated the page can at any later time raise any event on the client side. 2. The client side script can at any time raise any event on the server side (meaning inside the script that initially generated the page). 3. It must work trough existing Internet infrastructure, including strict firewalls and proxies. 4. It should also be possible to open extra websockets to other scripts - possibly trough the XMLHttpRequest object. The above requirements implies that any standard URL can deliver a web socket (since the web socket piggybacks with the original page response). Today requirement 1 can partly be achieved by never completing the transfer of the HTML-document: whenever the server wants to raise an event on the client side it appends "<script>eventhandler(data)</script>" and still does not close the transfer. Main problem here is that the onload event is never fired... Number 2 can be achieved by using XMLHttpRequest - but this starts another script instance on the server for each event raised from the client, and that is inefficient. Since the communication is directly to the script that generated the page, we by default have an URL scheme and all virtual hosting problems are solved. Also there is no need for cookies or other authentication schemes to be sure which page the server is talking to. (imagine the customer having two separate browser windows, both trying to talk to the same chat server - it brings in a lot of problems that are not solved by simple cookies). Number 3 requires that we use port 80 and 443, or that all restrictive firewalls in the world is reconfigured to open extra ports as well. Number 4 is implied since 1 and 2 requires the websocket to piggyback the original response. An AJAX request is basically a page request to an URL - so a websocket should be able to piggyback it. Also security restrictions defined for XHR should apply for WebSockets. I do not care how this is achieved - but as a busy programmer I do not want to spend hours researching how to implement this. Everything I need should be provided by HTML 5 compliant browsers and the webserver/cgi (e.g. Apache/PHP) interface.
Received on Friday, 25 July 2008 16:48:46 UTC