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: ann...@annevk.nl > To: travis.leith...@microsoft.com > CC: tyosh...@google.com; slightly...@google.com; email@example.com > Subject: Re: Overlap between StreamReader and FileReader > > On Thu, May 16, 2013 at 6:31 PM, Travis Leithead > <travis.leith...@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/ >