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
