Oh and one more thing:
Doesn't it seem strange that disconnect() causes an onclose event to be
dispatched? Should the method not be close() to be consistent with open(),
onopen, onclose?
/kel
On Fri, Jun 26, 2009 at 4:14 PM, Kelly Norton knor...@google.com wrote:
One thing about postMessage that I'm curious about. Since it has to report
failure synchronously by throwing an INVALID_STATE_ERR, that seems to imply
that all data must be written to a socket before returning and cannot be
asynchronously delivered to an I/O thread without adding some risk of
silently dropping
messages. Seems like the right choice would be to allow outbound messages to
drop, which would mean that developers would be forced to do their own
handshaking.
I'm also not sure there is good coverage of error conditions in the spec.
The only methods of error notification are exceptions in postMessage and
onclose. I had assumed that a WebSocket that fails to connect would invoke
onclose asynchronously, but I didn't see that in the spec. Without that you
don't even have the ability to know if a socket failed to establish a
connection (short of readyState polling). The spec also doesn't indicate
that the readyState should transition to CLOSED on connection failure.
(Description of the disconnect() method is careful to mention that it closes
a connection or a connection attempt, but description of when onclose is
fired just mentions a connection closing). I definitely think there should
be a way to receive an event if a connection fails to establish; I would
hate to have to poll another readyState.
/kel
On Fri, Jun 26, 2009 at 1:34 PM, Drew Wilson atwil...@google.com wrote:
Yes, but the closed state of a given WebSocket doesn't have to exactly
match the state of the underlying TCP connection, in the same way that
document.cookies doesn't exactly match the current set of cookies that the
network stack may be tracking (they can differ when HTTP responses are
received in the background while JS is executing).
So if the remote server closes the TCP connection, it generates a close
event which marks the WebSocket as closed. It means that you could have a
situation where you post messages to a WebSocket which aren't received by
the server because the connection is closed, but that's true regardless due
to the asynchronous nature of the networking protocol.
-atw
On Fri, Jun 26, 2009 at 9:52 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson atwil...@google.comwrote:
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.comwrote:
However, users can't usefully check the readyState to see if the
WebSocket is still open because there are not and cannot be any
synchronization guarantees about when the WebSocket may close.
Is this true? Based on our prior discussion surrounding cookies, it
seems like as a general rule we try to keep state from changing dynamically
while JS code is executing for exactly these reasons.
I think this is a very different beast. The state of a network
connection may change asynchronously whether we like it or not. Unlike
who may access cookies or local storage, the state of the network
connection is not something we solely control.
-Darin
--
If you received this communication by mistake, you are entitled to one free
ice cream cone on me. Simply print out this email including all relevant
SMTP headers and present them at my desk to claim your creamy treat. We'll
have a laugh at my emailing incompetence, and play a game of ping pong.
(offer may not be valid in all States).
--
If you received this communication by mistake, you are entitled to one free
ice cream cone on me. Simply print out this email including all relevant
SMTP headers and present them at my desk to claim your creamy treat. We'll
have a laugh at my emailing incompetence, and play a game of ping pong.
(offer may not be valid in all States).
