W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: Overlap between StreamReader and FileReader

From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 13 Sep 2013 22:11:40 +0900
Message-ID: <CAH9hSJYXwzcabqyy3ZTQHy1m-DkA58sHR1dHxO12-fwAmCY3Qg@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: Isaac Schlueter <i@izs.me>, Jonas Sicking <jonas@sicking.cc>, Austin William Wright <aaa@bzfx.net>, Domenic Denicola <domenic@domenicdenicola.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>
> Le 13/09/2013 14:23, Takeshi Yoshino a écrit :
>
> Do you mean that those data producer APIs should be changed to provide
> read-by-delta-data, and manipulation of data by js code should happen there
> instead of at the output of Stream?
>
>
>
> Yes, exactly, except if you/someone see another way of getting the data
> inside the browser and turning the flow into a stream without using these
> APIs.
>

I agree that there're various states and things to handle for each of the
producer APIs, and it might be judicious not to convey such API specific
info/signal through Stream.

I don't think it's bad to convert xhr.DONE to stream.close() manually as in
your example
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html.

But, regarding flow control, as I said in the other mail just posted, if we
start thinking of flow control more seriously, maybe the right approach is
to have unified flow control method and the point to define such a
fine-grained flow control is Stream, not each API. If we're not, yes, maybe
your proposal (deltaResponse) should be enough.
Received on Friday, 13 September 2013 13:12:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:13 UTC