[whatwg] Thread to run Web Socket feedback from the protocol ?
ian at hixie.ch
Wed Dec 9 04:39:17 PST 2009
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
> 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg