On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino <tyosh...@google.com>wrote:
> On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte <vitteayme...@gmail.com>wrote: > >> - pause: pause the stream, do not send eof >> > >> > Sorry, what will be paused? Output? > http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0059.html http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Pause.2Fresume So, you're suggesting that we make Stream be a convenient point where we can dam up data flow and skip adding methods to pausing data producing and consuming to producer/consumer APIs? I.e. we make it able to prevent data queued in a Stream from being read. This typically means asynchronously suspending ongoing pipe() or read() call on the Stream with no-argument or very large argument. > > >> - unpause: restart the stream >> >> And flow control should be back and explicit, not sure right now how to >> define it but I think it's impossible for a js app to do a precise flow >> control, and for existing APIs like WebSockets it's not easy to control the >> flow and avoid in some situations to overload the UA. >> >