RE: Overlap between StreamReader and FileReader

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: annevk@annevk.nl
> To: travis.leithead@microsoft.com
> CC: tyoshino@google.com; slightlyoff@google.com; public-webapps@w3.org
> Subject: Re: Overlap between StreamReader and FileReader
> 
> On Thu, May 16, 2013 at 6:31 PM, Travis Leithead
> <travis.leithead@microsoft.com> 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
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg569
> 
> 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.
> 
> 
> --
> http://annevankesteren.nl/
>