Re: [whatwg] nested hashchange events
On Thu, Jun 25, 2009 at 6:19 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 25 Jun 2009, Olli Pettay wrote: Also, what is the reason for if the Document's current document readiness is the string 'complete' requirement? I often click fragment links while the page is still loading, especially when the page is large or slow loading. Why shouldn't the page get notified that it has scrolled to some new location because of fragment id change. The event is intended for applications that use the #fragid as a way of storing app state. The expectation is that such an app would not be ready to handle state changes until the 'load' event has fired, and that the 'load' event would take into account whatever the #fragid is at that time. But couldn't a page store state in the hash while the page is still loading? At least in Firefox changing the hash while the page is loading works just as well (with regards to activating back/forward, and with regards to not reloading but rather just scrolling) while the page is still loading, as it does after the load event has fired. A slow loading image file will delay the load event, however there's no reason the scripts on the page wouldn't be able to deal with any user interaction just as if the image had loaded. / Jonas
Re: [whatwg] [html5] r3316 - [e] (0) A quick introduction to HTML.
The new quick introduction includes: Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it is a keyword, but generally will be quoted. -- http://www.whatwg.org/html5#a-quick-introduction-to-html Generally will be seems to be a prediction that the spec doesn't need to make, and could be seen as a recommendation for authors to quote attributes even when they're unnecessary. Could we simply omit that (finishing the sentence at keyword)? Smylers
Re: [whatwg] [html5] r3323 - [] (0) Add rules for improving compat with XSLT 1.0. (bug 6776)
wha...@whatwg.org writes: + /dlh3 id=dom-based-xslt-1.0-processorsspan class=secno3.7 /spanDOM-based XSLT 1.0 processors/h3 + pXSLT 1.0 processors outputting to a DOM when the output method is + html (either explicitly or via the defaulting rule in XSLT 1.0) + are affected as follows:/p + + pIf the transformation program outputs an element in no namespace, + the processor must ... snip Should this text be marked up as an implementation requirement? Smylers
Re: [whatwg] [html5] r3316 - [e] (0) A quick introduction to HTML.
Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it is a keyword [*or a number*]. IMHO, Chris
[whatwg] Offline Conformance Checkers
Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value not explicitly defined in this specification is allowed or not. -- http://www.whatwg.org/html5#other-metadata-names I think we should allow conformance checkers which can be run on local files without an internet connection, but the above appears to deem them non-conforming. The general conformance requirements include this get-out clause, but it isn't broad enough to cover this case: User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. -- http://www.whatwg.org/html5#conformance-requirements Smylers
[whatwg] Issues with Web Sockets API
Hello, I'm very excited about the concept of web sockets and look forward to building apps with it but the web sockets API at http://dev.w3.org/html5/websockets/ has some issues. Many issues seem to be inherited from the original XmlHttpRequest specification, which was extremely useful but not a very good spec. I'm sure I'm not the only one who has spent far too many hours dealing with underspecified or poorly implemented XHR flavors and would love to avoid doing that in the future. I know several vendors have started work on implementations already but I hope that this feedback is still useful. 0) postMessage() looks as if it is intended to mimic MessagePort.postMessage() or , but the arguments and error conditions are different. While it would be conceptually nice to treat a web socket in the same way as a message port, it's not possible to treat the two postMessage() functions in the same way. I'd recommend the WebSocket version be renamed to something like send() to avoid confusion and false expectations. There's similar oddness with receiving events that satisfy the MessageEvent interface - since all fields except 'data' will necessarily be invalid I don't see the value in receiving something more complex. 1) The 'readyState' attribute can never actually be used by an application and is redundant. Initially, the 'readyState' attribute is set to CONNECTING, but while the object is in this state the user is not permitted to interact with the WebSocket in any way. The only useful thing that a user could do is set event handlers and wait for the 'open' event to fire. When the WebSocket becomes connected, the readyState becomes 1 and the 'open' event is fired. Once the WebSocket is open, the spec states that whenever the connection is closed the readyState changes to CLOSED and a 'close' event is enqueued. 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. A user will have to wrap all calls to postMessage() (or send() if the function is renamed) in a try/catch block in order to handle INVALID_STATE_ERRs. Once the 'close' event has been received the readyState attribute is useless since the state of the WebSocket is known and can never change. I think 'readyState' should just go away since an application will have to keep track of state updates through the fired events and use try/catch blocks around all API calls anyway. - James
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote: 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.
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote: 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
Re: [whatwg] Issues with Web Sockets API
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.com wrote: 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
Re: [whatwg] Issues with Web Sockets API
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.com wrote: 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).
Re: [whatwg] Issues with Web Sockets API
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).
Re: [whatwg] Issues with Web Sockets API
Does disconnect() attempt to flush pending messages or drop them? There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere. Something that might add value is an onmessagesent event that fires after a postMessage has put the bits on the wire. postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire. On Fri, Jun 26, 2009 at 1:19 PM, Kelly Norton knor...@google.com wrote: 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.orgwrote: 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).
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 1: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. I don't think that's the intent of the spec - the intent is that INVALID_STATE_ERR is sent if the port is in a closed state, not if there's an I/O error after send. But Michael's right, I don't think there's any way to determine that the server received the message - I guess the intent is that applications will build their own send/ack protocol on top of postMessage(), as you note. -atw
Re: [whatwg] Issues with Web Sockets API
Not changing variables out from under executing JavaScript makes a lot of sense, but if that was the case then it's not clear when the readyState could be updated. The spec states When the *Web Socket connection is closed*, the readyStatehttp://dev.w3.org/html5/websockets/#dom-websocket-readystate attribute's value must be changed to CLOSEDhttp://dev.w3.org/html5/websockets/#dom-websocket-closed (2), and the user agent must queue a task to fire a simple event called close at the WebSocket http://dev.w3.org/html5/websockets/#websocket object. If the browser cannot mutate the readyState until JavaScript stops running then it would either have to either enqueue a second task to change readyState at some point in the future or set the readyState right before dispatching the 'close' event. The latter would be much nicer to implement - but then it does make the readyState completely useless as it would always be exactly equivalent to the last event that was fired on a given WebSocket. The spec seems to be also a bit undecided about error handling. The postMessage() description says If the connection is not established ( readyState http://dev.w3.org/html5/websockets/#dom-websocket-readystate is not OPEN http://dev.w3.org/html5/websockets/#dom-websocket-open), it must raise an INVALID_STATE_ERR exception. The first part implies that trying to postMessage() when the underlying socket is disconnected requires an exception to the thrown synchronously, but if the readyState cannot be changed while javascript is running then the parenthetical would indicate that a browser could not throw an exception until the readyState was updated. An exception for 'too much data pending' has a similar problem - there's no way for the browser to know that there is too much data enqueued without blocking to check with its I/O thread (or process). An asynchronous model would be better with an error signaled by a later callback. I think a better way to do error handling is to have an asynchronous onerror callback or event when the browser notes that a message did not make it to the other side. - James On Fri, Jun 26, 2009 at 4:52 PM, Michael Nordman micha...@google.comwrote: Does disconnect() attempt to flush pending messages or drop them? There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere. Something that might add value is an onmessagesent event that fires after a postMessage has put the bits on the wire. postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire. On Fri, Jun 26, 2009 at 1:19 PM, Kelly Norton knor...@google.com wrote: 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.comwrote: 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
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 5:01 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 1: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. I don't think that's the intent of the spec - the intent is that INVALID_STATE_ERR is sent if the port is in a closed state, not if there's an I/O error after send. But Michael's right, I don't think there's any way to determine that the server received the message - I guess the intent is that applications will build their own send/ack protocol on top of postMessage(), as you note. -atw The concept of a port being in a closed state is not very well defined - if the state means only the readyState status, then when can the state legally be updated? If it has some meaning closer to the state of the underlying connection, then it can't be queried synchronously without very expensive synching to the I/O thread or process. Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote: Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility. -atw
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote: Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? Classic networking problem... if you do send the ack... how does the ack sender know the other side has received it... and so on. One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility. Yes. But knowing if the data your queuing to be sent is backing up in your local system instead of being pushed out is different than knowing if the remote side has received it and processed it. The former can be done w/o changing the websocket network protocol, the latter cannot. -atw
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote: On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.comwrote: Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? Classic networking problem... if you do send the ack... how does the ack sender know the other side has received it... and so on. Precisely, and complicated by the fact that the app layers I've worked with don't actually expose TCP acks to the app, so you can't even tell that the remote side has acked your packets. One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility. Yes. But knowing if the data your queuing to be sent is backing up in your local system instead of being pushed out is different than knowing if the remote side has received it and processed it. The former can be done w/o changing the websocket network protocol, the latter cannot. Is the queued up data is backing up problem any different from somebody doing a ton of async XHR requests, some of which may need to be queued before being sent?
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 3:33 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote: On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.comwrote: Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? Classic networking problem... if you do send the ack... how does the ack sender know the other side has received it... and so on. Precisely, and complicated by the fact that the app layers I've worked with don't actually expose TCP acks to the app, so you can't even tell that the remote side has acked your packets. One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility. Yes. But knowing if the data your queuing to be sent is backing up in your local system instead of being pushed out is different than knowing if the remote side has received it and processed it. The former can be done w/o changing the websocket network protocol, the latter cannot. Is the queued up data is backing up problem any different from somebody doing a ton of async XHR requests, some of which may need to be queued before being sent? No. But the difference is each XHR tells you when its been sent and gives you the response when its received. With this info, apps can rate limit things. WebSocket.postMessage doesn't tell you when that message has been sent. Suppose your sending 'i'm alive' messages. If the message you sent 5 minutes ago hasn't really been sent, you wouldn't want to queue another 'i'm alive'. If you're uploading a large data set incrementally across many distinct postMessage calls (perhaps to leave room for other control messages interspersed amoungst them, or to present progress info), how do you know when to queue more data to be sent.
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 3:47 PM, Michael Nordman micha...@google.comwrote: No. But the difference is each XHR tells you when its been sent and gives you the response when its received. With this info, apps can rate limit things. WebSocket.postMessage doesn't tell you when that message has been sent. Well, yes and no. You know when you get a response back because readyState = HEADERS_RECEIVED. But there's nothing between OPEN and HEADERS_RECEIVED that tells you anything about bits on the wire. Suppose your sending 'i'm alive' messages. If the message you sent 5 minutes ago hasn't really been sent, you wouldn't want to queue another 'i'm alive'. If your goal is never to send another heartbeat until you know your previous one has been delivered, then that seems like a motivation to add an app-layer heartbeat ack. Treating queued but not yet put on the wire any differently from put on the wire but not yet acked or acked, but still queued for delivery to the app layer on the remote end seems like a false distinction. If you're uploading a large data set incrementally across many distinct postMessage calls (perhaps to leave room for other control messages interspersed amoungst them, or to present progress info), how do you know when to queue more data to be sent. I could keep saying app level acks! but I don't want to beat a dead horse, and honestly, I'm not entirely certain that I'm right :)
Re: [whatwg] One document or two?
On Wed, Jun 24, 2009 at 8:49 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Wed, Jun 24, 2009 at 3:15 AM, Ian Hicksoni...@hixie.ch wrote: I don't think alternative style sheets are evil; in fact, they seem to be quite within the architecture of the Web. Surely you don't think that, e.g., GMail is evil for having the same URL for whether your contact list is hidden or expanded. I can't give other people links to my Gmail URLs anyway, since they don't know my password (I hope). On the other hand, if I'm reading the author version of HTML 5 and want to quote a portion of it to someone with a link, it would be rather confusing if they said Hey, that's not what it says! Publicly-viewable *documents* -- not necessarily applications which may have no stable state anyway -- whose *contents* -- not UI -- differ as dramatically as this should have different URLs. That's how documents on the web have always worked, and that's what people expect. They do: http://www.whatwg.org/specs/web-apps/current-work/?style=complete http://www.whatwg.org/specs/web-apps/current-work/?style=author http://www.whatwg.org/specs/web-apps/current-work/?style=highlight It's just that the url http://www.whatwg.org/specs/web-apps/current-work/ refers to specific resource based on the value of a cookie. The resources themselves are directly linkable, however. ~TJ
Re: [whatwg] Issues with Web Sockets API
On 26.6.09 13:52, Michael Nordman wrote: There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere. You can't really know data has been successfully sent until you get a response that acknowledges it. Getting it on the wire doesn't mean it'll actually be received; I'm not really sure how much value knowing that's happened actually has, other than for doing network diagnostics (which hardly seems a use case to support). postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire. Nothing prevents the data from being thrown in a FIFO queue until it actually can be sent, and I don't see a reason why OOM in the event queueing failed should be handled differently from any other OOM. Jeff
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden jwalden+wha...@mit.edujwalden%2bwha...@mit.edu wrote: On 26.6.09 13:52, Michael Nordman wrote: There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere. You can't really know data has been successfully sent until you get a response that acknowledges it. Getting it on the wire doesn't mean it'll actually be received; I'm not really sure how much value knowing that's happened actually has, other than for doing network diagnostics (which hardly seems a use case to support). Progress bars are routinely implemented without get hi-level application acks from the other side. XMLHttpRequest.upload.onprogress is one such example. diagnostics Cell-phone signal strength bars are a form of diagnostics... existence proof of diagnostics being a significant use case. postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire. Nothing prevents the data from being thrown in a FIFO queue until it actually can be sent, and I don't see a reason why OOM in the event queueing failed should be handled differently from any other OOM. This info about the status of the WebSocket would be easy to provide to callers of this API. There are easily found valid use cases for this additional status info. What compelling reason is there to not do so? Seems like low-hanging fruit if you ask me. Jeff
Re: [whatwg] Issues with Web Sockets API
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote: On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote: Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP. - James Every time I've written a response/reply protocol on TCP I've needed to put in my own acks - how else do you know your message has been delivered to the remote app layer? This seems especially true given that WebSocket connections may be proxied. -Darin One could argue that WebSockets should do this for you, but I like leaving this up to the app as it gives them more flexibility. -atw
