Re: Overlap between StreamReader and FileReader

I skimmed the thread before starting this and saw that you were pointing
out some issues but didn't think you're opposing so much.

----

Let me check requirements.

a) We don't want to introduce a completely new object for streaming HTTP
read/write, but we'll realize it by adding some extension to XHR.

b) The point to connect the I/O API and XHR should be only the send()
method argument and xhr.response attribute if possible.

c) The semantics (attribute X is valid when state is ..., etc.) should be
kept same as other modes.

d) The I/O API needs to work with synchronous XHR.

e) Resource for already processed data should be able to be released
explicitly as the user instructs.

f) Reading with maxSize argument (don't read too much).

g) The I/O API should allow for skipping unnecessary data without creating
a new object for that.

Not requirement

h) Some people wanted Stream to behave like not an object to store the data
but kinda dam put between response attribute and XHR's internal buffer (and
network stack) expecting that XHR doesn't consume data from the network
until read operation is invoked on Stream object. (i.e. Stream controls
data flow in addition to callback invocation timing). But it's no longer
considered to be a requirement.

i) Reading with size argument (invoke callback only when data of the
specified amount is ready. Only data of the specified size at the head of
stream is passed to the handler)


On Fri, May 17, 2013 at 2:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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/
>