[whatwg] Issues with Web Sockets API
jamesr at google.com
Fri Jun 26 14:11:08 PDT 2009
On Fri, Jun 26, 2009 at 5:01 PM, Drew Wilson <atwilson at google.com> wrote:
> On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton <knorton at 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg