<div class="gmail_quote">On Fri, Jun 26, 2009 at 5:01 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton <span dir="ltr"><<a href="mailto:knorton@google.com" target="_blank">knorton@google.com</a>></span> wrote:<br></div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. </blockquote>
<div><br></div></div><div>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.</div>
<div><br></div><div>-atw</div></div>
</blockquote></div><br><div>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.</div>
<div><br></div><div>Forcing applications to build their own send/ack functionality would be pretty tragic considering that WebSockets are built on top of TCP.</div><div><br></div><div>- James</div>