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

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.  
Synchronous dispatch seems more useful to authors, as it gives more  
guarantees about connection state when handling the event.  
Implementations have always dealt with the necessary book-keeping to  
present asynchronous networking events in a synchronous manner, and I  
don't think think it's been a problem.

An implementation that keeps parts of WebSocket logic in a different  
thread or process will need to queue readyState event changes as you  
describe, but that will be an implementation detail.

> 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.

- WBR, Alexey Proskuryakov

Received on Friday, 4 December 2009 10:07:32 UTC