> <span class="Apple-style-span" style="border-collapse: collapse; ">Obviously we need more web platform capabilities to make such use cases a reality, but they are foreseeable and we should deal with them in some reasonable way.</span><div>
<span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">Couldn't agree more.</span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">The proposed websocket interface is too dumbed down. The caller doesn't know what the impl is doing, and the impl doesn't know what the caller is trying to do. As a consequence, there is no "reasonable" action that either can take when buffers start overflowing. Typically, the network layer provides sufficient status info to its caller that, allowing the higher level code to do something reasonable in light of how the network layer is performing. That kind of status info is simply missing from the websocket interface. I think its possible to add to the interface features that would facilitate more demanding uses cases without complicating the simple use cases. I think that would be an excellent goal for this API.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><div class="gmail_quote">On Mon, Jul 27, 2009 at 5:30 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Jul 27, 2009, at 2:44 PM, Drew Wilson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
There's another option besides blocking, raising an exception, and dropping data: unlimited buffering in user space. So I'm saying we should not put any limits on the amount of user-space buffering we're willing to do, any more than we put any limits on the amount of other types of user-space memory allocation a page can perform.<br>

</blockquote>
<br></div>
I think even unlimited buffering needs to be combined with at least a hint to the WebSocket client to back off the send rate, because it's possible to send so much data that it exceeds the available address space, for example when uploading a very large file piece by piece, or when sending a live media stream that requires more bandwidth than the connection can deliver. In the first case, it is possible, though highly undesirable, to spool the data to be sent to disk; in the latter case, doing that would just inevitably fill the disk. Obviously we need more web platform capabilities to make such use cases a reality, but they are foreseeable and we should deal with them in some reasonable way.<br>

<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br></div>