The idea did not come from mimicing WebRTC: - pause/unpause: insert pause in the stream, stop processing the data when pause is reached (but don't close the operation, see below), buffer next data coming in, restart from pause on unpause Use case: flow control, window flow control gets empty, wait signal from the receiver to reinitialize the window and restart - stop/resume : different from close, stop: insert a specific eof-stop in the stream, the API closes the operation while receiving it, buffer data, restart the operation on resume in the state it was before receiving eof-stop It's more tricky, use case is the one I gave before: specific progressive hash, close a hash and resume it from the state it was before closing it, the feature has been asked several time to node for example. Whether it's "implementable", I don't know, but I don't see why it could not be, uses cases are real (myself but I am not the only one) Regards, Aymeric Le 30/10/2013 12:49, Takeshi Yoshino a écrit : > On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino <tyoshino@google.com > <mailto:tyoshino@google.com>> wrote: > > On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte > <vitteaymeric@gmail.com <mailto:vitteaymeric@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. > -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Received on Sunday, 3 November 2013 22:31:35 UTC