On 09.12.2009, at 4:39, 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.
This is only an issue if WebSocket handling is performed in some other
thread of execution (and even then, it's not really an issue). But I
don't think that's the best way to think about it.
Data from network is only processed as an event loop task, so it's
possible and desirable to dispatch events right away. Both single-
process and multi-process implementations I know of do so - and even
if some future implementation wants to run WebSocket code on a
different thread, they can easily implement synchronous event dispatch
by posting an event and waiting for it to be processed.
This is no different from how XMLHttpRequest works - browser engines
do not need to queue tasks for onreadystate events, and do not - those
are dispatched right away.
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?
I don't understand what this means.
- WBR, Alexey Proskuryakov
