Can you please go into a bit more detail? I've read through the thread, and it 
mostly focuses on the details of how a Stream is received from XHR and what 
behaviors can be expected - it only lightly touches on how you can operate on a 
stream after it is received.
The StreamReader by design mimics the FileReader, in order to give a consistent 
experience to developers. If we agree the FileReader has some flaws and we want 
to take an opportunity to address them with StreamReader, or an alternative, 
then I think that is reasonable. I do agree the API should allow for scenarios 
where data can be discarded, given that is an advantage of a Stream over a Blob.
That said, Anne, what is your suggestion for how Streams can be consumed?
Also, apologies for being a bit late to the conversation - I missed the 
conversations the past month. I'm now hoping to solicit more feedback and 
update the Streams spec accordingly.

> Date: Thu, 16 May 2013 18:41:21 +0100
> From:
> To:
> CC:;;
> Subject: Re: Overlap between StreamReader and FileReader
> On Thu, May 16, 2013 at 6:31 PM, Travis Leithead
> <> wrote:
> > Since we have Streams implemented to some degree, I'd love to hear 
> > suggestions to improve it relative to IO. Anne can you summarize the points 
> > you've made on the other various threads?
> I recommend reading through
> Problems:
> * Too much complexity for being an Blob without synchronous size.
> * The API is bad. The API for File is bad too, but we cannot change
> it, this however is new.
> And I think we really want an IO API that's not about incremental, but
> can actively discard incoming data once it's processed.
> --

Reply via email to