Le 24/09/2013 21:24, Takeshi Yoshino a écrit :
On Wed, Sep 25, 2013 at 12:41 AM, Aymeric Vitte
<[email protected] <mailto:[email protected]>> 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
