Re: Overlap between StreamReader and FileReader

Sorry, I just took over this work and so was misunderstanding some point in
the Streams API spec.

On Fri, May 17, 2013 at 6:09 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

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


Yes. "Read data is automatically released" model is simple and good.

I thought the spec is clear about this but sorry it isn't. In the spec we
should say that StreamReader invalidates consumed data in Stream and buffer
for the invalidated bytes will be released at that point. Right?


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


I wanted to understand clearly what you meant by "discard" in your posts. I
wondered if you were suggesting that we have some method to skip incoming
data without creating any object holding received data. I.e. something like

s.skip(10);
s.readFrom(10);

not like

var useless_data_at_head_remaining = 256;
ondata = function(evt) {
  var bytes_received = evt.data.size();
  if (useless_data_at_head_remaining > bytes_received) {
    useless_data_at_head_remaining -= bytes_received;
    return;
  }

  processUsefulData(evt.data.slice(uselesss_data_at_head_remaining));
}

If you meant the latter, I'm ok. I'd also call the latter "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.
>

In the thread, Glenn was discussing what's consumer and what's producer,
IIRC.

I supposed that the idea behind Stream is providing a flow control
interface to control XHR has internal buffer. When the internal buffer is
full, it stops reading data from the network (e.g. BSD socket). The buffer
will be drained when and only when read operation is made on the Stream
object.

Stream has infinite length, but shouldn't have infinite capacity. It'll
swell up if the consumer (e.g. media stream?) is slow.

Of course, browsers would set some limit, but it should rather be well
discussed in the spec. Unless the limit is visible to scripts, they cannot
know if it can watch only "load" event or need to handle "progress" event
and consume arrived data progressively to process all data.


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

What use cases do you have in your mind? Your example in the thread was
passing one to <video> but also accessing it manually using StreamReader. I
think it's unknown in what timing and how much <video> consumes data from
the Stream to the script and it's really hard make such coordination
successful.

Are you thinking of use case like mixing chat data and video contents in
the same HTTP response body?