Re: Overlap between StreamReader and FileReader

On Tue, Jul 30, 2013 at 10:27 PM, Takeshi Yoshino <tyoshino@google.com> wrote:
> On Tue, Jul 30, 2013 at 12:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> >> could contain an encoding. Then when stream.readText is called, if
>> >> there's an explicit encoding, it would use that encoding when
>> >
>> >
>> > Do you think it should also have overrideMimeType like XHR?
>>
>> I think that use case is rare enough that we can solve it by letting the
>> author create a new Stream object, which presumably would allow specifying a
>> type for that stream, and then feed that new stream the contents of the old
>> stream.
>
> OK.
>
> One question about readText is what size should mean and how to handle
> incomplete chunk.
>
> a) maxSize means the size of DOMString. readText reads data until it builds
> DOMString of maxSize or reached EoF
> b) maxSize means the size of raw bytes
> b-i) buffer incomplete bytes for next read
> b-ii) fail if decoder didn't consume all read data (of maxSize bytes)
>
> b-ii) is simple but inconvenient. user need to know the number of bytes the
> next text data occupies in advance
>
> maybe b-i) and in case read() is issued after incomplete readText, an
> exception should be thrown. This is kind of mutual exclusiveness Anne was
> worrying about.

This is an excellent question. I have the same reaction regarding b-ii
and b-i. And I'd also lean towards b-i with the caveat that you are
raising.

Another issue is that it would be great to support reading null
terminated strings. I.e. rather than reading a particular size (binary
or decoded size), being able to read until a null terminator is
consumed. That seems like something that is likely to come up.

I do agree that having a single stream type which represents both
binary streams and text streams does make things more painful.
Specifically it makes the b-i solution above more painful.

However having separate types for binary and text streams also creates
problems. Specifically it makes it a lot harder to parse a data format
which contains combination of text and binary data. I don't see a good
solution to supporting that without bringing in worse issues than the
b-i issue above.

So I'm personally still leaning towards sticking both binary and text
support on the same Stream interface. And then using b-i above.
Reading until null termination can probably wait for now.

But I'd be interested to hear counter proposals.

/ Jonas

Received on Wednesday, 31 July 2013 07:28:54 UTC