Re: Not making partial result available during FileReader.readAsText()?

I think the spec should say MUST here, rather than SHOULD. Streaming
contents seems as useful for text files as for binary files.

The one thing that was tricky for us when implementing this was
charset detection. We can't really expose any data until we've decided
what charset to decode it with. However when loading normal pages over
http the same situation arises, and all major browsers support
streaming there.

So I consider it a bug that firefox doesn't support this yet. It's
something we should fix.

/ Jonas

On Fri, Apr 9, 2010 at 6:33 PM, Jian Li <jianli@chromium.org> wrote:
> Should we really want to support this? As I know, FF 3.6 does not support
> this in its current FileReader implementation. I just want to understand if
> there is a strong need for this.
>
> On Fri, Apr 9, 2010 at 5:49 PM, Michael Nordman <michaeln@google.com> wrote:
>>
>> Seems pretty clear from the snippet you provided, it says you SHOULD
>> provide partially decoded results in the result attribute as progress is
>> made.
>>
>> On Thu, Apr 8, 2010 at 8:31 PM, Jian Li <jianli@chromium.org> wrote:
>>>
>>> For FileReader.readAsText, the spec seems to allow partial file data
>>> being decoded and saved in the result attribute when progress event is
>>> fired:
>>>
>>> Make progress notifications. As the bytes from the fileBlob argument are
>>> read, user agents SHOULD ensure that on getting, the result attribute
>>> returns partial file data representing the number of bytes currently loaded
>>> (as a fraction of the total) [ProgressEvents], decoded in memory according
>>> to the encoding determination.
>>>
>>> The partial file data read so far might not get decoded completely. Could
>>> we choose not to decode the partial result till we retrieve all the data,
>>> just like what FileReader.readAsDataURL does?
>>
>
>

Received on Saturday, 10 April 2010 01:59:51 UTC