[whatwg] Websockets Client API

[Toni Ruottu]

I believed that the browser is expected to somehow magically delay the
events until a callback has been registered. At least that is how it
seems to work at the moment. The specification could be clearer about
this.

While IETF and W3C are involved in standardizing the protocol, the
part you are dealing with falls in between of the two specifications.
I think IETF does not usually specify APIs for the protocols, and W3C
specifies browser APIs for untrusted javascript code.

You are expected to look at the IETF spec and design an API that suits
the environment you are programming for. You may want to look at the
W3C specification, as some users may have used that API before they
start using your library. However the W3C specification only reveals
certain subset of the features that the IETF protocol defines. The
rationale behind this is that the browser may be running untrusted
code that needs to be restricted for security reasons.

  --Toni

On Mon, Feb 21, 2011 at 12:09 AM, Bruce Atherton <bruce at callenish.com> 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.
>
>