Re: [whatwg] Issues with Web Sockets API

[Darin Fisher]

On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson  wrote:

>
>
> On Fri, Jun 26, 2009 at 2:11 PM, James Robinson  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
>
>

Re: [whatwg] Issues with Web Sockets API

[Michael Nordman]

On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden

> 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

[Jeff Walden]

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] One document or two?

[Tab Atkins Jr.]

On Wed, Jun 24, 2009 at 8:49 AM, Aryeh Gregor wrote:
> On Wed, Jun 24, 2009 at 3:15 AM, Ian Hickson 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

[Drew Wilson]

On Fri, Jun 26, 2009 at 3:47 PM, Michael Nordman wrote:

>
>
> 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] Issues with Web Sockets API

[Michael Nordman]

On Fri, Jun 26, 2009 at 3:33 PM, Drew Wilson  wrote:

>
>
> On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman wrote:
>
>>
>>
>> On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson  wrote:
>>
>>>
>>>
>>> On Fri, Jun 26, 2009 at 2:11 PM, James Robinson 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.
>>
>
>
> 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

[Drew Wilson]

On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman wrote:

>
>
> On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson  wrote:
>
>>
>>
>> On Fri, Jun 26, 2009 at 2:11 PM, James Robinson 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.
>

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

[Michael Nordman]

On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson  wrote:

>
>
> On Fri, Jun 26, 2009 at 2:11 PM, James Robinson  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

[Drew Wilson]

On Fri, Jun 26, 2009 at 2:11 PM, James Robinson  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

[James Robinson]

On Fri, Jun 26, 2009 at 5:01 PM, Drew Wilson  wrote:

>
>
> On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton  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

[James Robinson]

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 
readyState
attribute's
value must be changed to
CLOSED (2),
and the user agent must queue a task to fire a simple event called close at
the 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  is
not 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 wrote:

> 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  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  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 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 i

Re: [whatwg] Issues with Web Sockets API

[Drew Wilson]

On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton  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

[Michael Nordman]

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  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  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  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 wrote:
>>>
 On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson wrote:

>
> On Fri, Jun 26, 2009 at 9:18 AM, James Robinson 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

>>>
>>>
>>
>>
>> --
>> 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

[Kelly Norton]

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  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  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  wrote:
>>
>>> On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson wrote:
>>>

 On Fri, Jun 26, 2009 at 9:18 AM, James Robinson 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
>>>
>>
>>
>
>
> --
> 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

[Kelly Norton]

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  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  wrote:
>
>> On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson  wrote:
>>
>>>
>>> On Fri, Jun 26, 2009 at 9:18 AM, James Robinson 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
>>
>
>


-- 
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

[Drew Wilson]

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  wrote:

> On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson  wrote:
>
>>
>> On Fri, Jun 26, 2009 at 9:18 AM, James Robinson 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

[Darin Fisher]

On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson  wrote:

>
> On Fri, Jun 26, 2009 at 9:18 AM, James Robinson  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

[Drew Wilson]

On Fri, Jun 26, 2009 at 9:18 AM, James Robinson  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.

[whatwg] Issues with Web Sockets API

[James Robinson]

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

[whatwg] Offline Conformance Checkers

[Smylers]

  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

Re: [whatwg] [html5] r3316 - [e] (0) A quick introduction to HTML.

[Kristof Zelechovski]

  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

Re: [whatwg] [html5] r3323 - [] (0) Add rules for improving compat with XSLT 1.0. (bug 6776)

[Smylers]

wha...@whatwg.org writes:

> +  3.7 
> DOM-based XSLT 1.0 processors
>  
> +  XSLT 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:
> +
> +  If the transformation program outputs an element in no namespace,
> +  the processor must ... 

Should this text be marked up as an implementation requirement?

Smylers

Re: [whatwg] [html5] r3316 - [e] (0) A quick introduction to HTML.

[Smylers]

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] nested hashchange events

[Jonas Sicking]

On Thu, Jun 25, 2009 at 6:19 PM, Ian Hickson 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