[whatwg] Thread to run Web Socket feedback from the protocol ?

[Ian Hickson]

On Fri, 4 Dec 2009, Alexey Proskuryakov wrote:
> On 03.12.2009, at 18:07, Ian Hickson wrote:
> 
> > I could change the spec to make the readyState attribute changes be 
> > queued along with the event dispatch,
> 
> I do not understand why the events are queued, to begin with. 

How else would it work? We can't interrupt a running script to run an 
event dispatch, or fire an event in the middle of the HTML parser running, 
or fire an event while a plugin is doing sychronous DOM changes -- we 
always have to wait for the event loop's current running task to have 
finished. That's what queuing a task means.


> > but then we'd have a situation whereby the "actual" state of the 
> > websocket object might not match the state returned by the attribute.
> 
> This doesn't sounds like an issue to me. The "actual" state is always 
> out of sync, because client and server have different ideas of actual 
> state. So does an Ethernet controller, OS interrupt handler, low level 
> OS networking code, etc. The only state that matters client-side is what 
> JavaScript code sees, and all the intermediaries must (and do) act as if 
> that were the real thing.

I'm not talking about the state of the network, but about the state of the 
object itself. You would end up in situations where, for instance, sending 
would work fine, even though the state attribute said that you hadn't 
connected yet.

I suppose we could get around that by saying that the attribute _is_ the 
state, so even if the object thinks it has a connection, the send() would 
still fail until the first event has fired and the state has changed... 
Would that be acceptable?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'