Re: Overlap between StreamReader and FileReader

On Thu, May 16, 2013 at 10:14 PM, Takeshi Yoshino <tyoshino@google.com> wrote:
> 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.

Well yes. I removed integration from XMLHttpRequest a while back too.


> Let me check requirements.
>
> d) The I/O API needs to work with synchronous XHR.

I'm not sure this is a requirement. In particular in light of
http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/
and synchronous being worker-only it's not entirely clear to me this
needs to be a requirement from the get-go.


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

Can't this happen transparently?


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

This would be equivalent to reading and discarding?


> 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'm not sure what this means. It sounds like something that indeed
should be transparent from an API point-of-view, but it's hard to
tell.


We also need to decide whether a stream supports multiple readers or
whether you need to explicitly clone a stream somehow. And as far as
the API goes, we should study existing libraries.


--
http://annevankesteren.nl/

Received on Friday, 17 May 2013 09:10:24 UTC