- From: Anthony Papillion <anthonyp@adcl.us>
- Date: Sun, 20 Feb 2011 18:28:09 -0600
Forgive me if I'm overlooking something here but couldn't the same thing be accomplished by wrapping the constructor code in a try/catch block? Anthony On 02/20/2011 04:09 PM, Bruce Atherton wrote: > I know that the IETF HyBi WG is defining the Websockets protocol, but I > believe that the definition of the browser API is still done through > HTML5. If I am wrong, please let me know. > > I've been reading through http://dev.w3.org/html5/websockets/ in an > effort to define a similar client interface for my Websockets library. I > am a bit stuck on how a connection is established, though. > > According to the spec, establishing a connection is done through the > Websocket object constructor on a background thread. This results in > the possibility that a connection could fire its open, error, and/or > close events before the user can set a handler for these events. For the > open and close events one could recover based on the ReadyState of the > object, albeit with additional complexity for every newly opened > Websocket connection, but any error events would be lost forever. > > Is there a reason not to have a separate open() call? This could be done > in the same asynchronous manner as described in Step 7 of the Websocket > constructor. The only difference would be that the user gets the > opportunity to fully configure the Websocket object before it is used to > establish a connection. >
Received on Sunday, 20 February 2011 16:28:09 UTC