Le 24/09/2013 21:24, Takeshi Yoshino a écrit : > On Wed, Sep 25, 2013 at 12:41 AM, Aymeric Vitte > <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote: > > Did you see > http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0593.html > ? > > > Yes. This example seems to be showing how to connect only > producer/consumer APIs which support Stream. Right? Yes but if something like createStream is generic then any API could support it, for further APIs or next versions it can be built in. > > In such a case, all the flow control stuff would be basically hidden, > and if necessary each producer/consumer/transformer/filter/etc. may > expose flow control related parameter in their own form, and configure > connected input/output streams accordingly. E.g. stream_xhr may choose > to have large write buffer for performance, or have small one and make > some backpressure to stream_ws1 for memory efficiency. Yes > > My understanding is that the flow control APIs like mine are intended > to be used by JS code implementing some converter, consumer, etc. > while built-in stuff like WebCrypt would be evolved to accept Stream > directly and handle flow control in e.g. C++ world. > > ---- > > BTW, I'm discussing this to provide data points to decide whether to > include flow control API or not. I'm not pushing it. I appreciate if > other participants express opinions about this. Not sure to get what you mean between your API flow control and built-in flow control... I think the main purpose of the Stream API should be to handle more efficiently streaming without having to handle ArrayBuffers copy, split, concat, etc, to abstract the use of ArrayBuffer, ArrayBufferView, Blob, txt so you don't spend your time converting things and to connect simply different streams. -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Received on Wednesday, 25 September 2013 13:55:36 UTC