- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 27 Jul 2009 17:51:09 -0700
> 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. Couldn't agree more. 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. On Mon, Jul 27, 2009 at 5:30 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Jul 27, 2009, at 2:44 PM, Drew Wilson wrote: > > >> >> 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. >> > > 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. > > Regards, > Maciej > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090727/435aaabe/attachment.htm>
Received on Monday, 27 July 2009 17:51:09 UTC